Author: leonid
Date: 13:10:29 08/11/00
Go up one level in this thread
On August 11, 2000 at 13:54:10, Larry Griffiths wrote: >On August 11, 2000 at 05:57:22, leonid wrote: > >>On August 11, 2000 at 00:02:39, Larry Griffiths wrote: >> >>>Leonid, >>> >>>I am wondering now if I am confusing BruteForce with Minmax. I always thought >>>BruteForce was generating ALL the moves (or another name for MinMax). >> >>It could be that I am confused with name. It happen to me often. Never mind. >>Will just say what I see as Brute Force. Brute Force look all the possibility in >>given position before it reach its decision. It is not forced to see all the >>moves in each ply for doing so. In MiniMax you see all moves (nodes) for each >>ply before saying your result. >> >> >>>Anyway, I ran your position to 6 plys and here are the results... >> >>Some data still is useful for me even if I am doubious about my Brute Force >>branching factor. >> >>> >>>TCBoard - RunMinMax() >>> >>>Elapsed Time= 1125.38 seconds >>> >>>Ply ---CAPTURES-- -----MOVES----- -----TOTAL----- ---Invalid--- >>> 1 5 30 35 2 >>> 2 130 1,065 1,195 93 >>> 3 6,613 35,468 42,081 2,107 >>> 4 199,119 1,282,187 1,481,306 107,805 >>> 5 8,725,158 43,530,271 52,255,429 2,555,427 >>> 6 281,688,872 1,585,505,759 1,867,194,631 132,999,965 >>> _____________ _______________ _______________ _____________ >>> 290,619,897 1,630,354,780 1,920,974,677 135,665,399 >>> >>> Captures/Moves Per Second= 1,706,964 >> >> >>What is interesting for me in your table is the "INVALID" number. Probably you >>generate invalid move in move generator and only lately you see if it is legal. >> > >This is indeed true. The postings here lean toward making move generation lean >and mean and doing checking on the back end in hopes the alpha-beta cutoffs will >eliminate the extra cpu overhead in validating moves. This is very interesting since it make me think about my recent speeding of my brute force search. Idea (said repeatedly by Bob and Tom) that illegal move generation have more sense that legal, because of effective alpha-beta cuts. I could not see. This is because I knew that average branching factor is between 4 and 7. Mainly around 5.5 for my program. With this number of moves to verify later, I have seen little chance to speed my program. What I found later is slightly more that 50% of all search in each ply is done after the first move was seen. So idea of using illegal moves have sense. Just try for start one illegal best move and only if this not work go into long legal moves generation. Still legal move generation have its sense for efficency in my program. >>Must I understand Capture/Moves as simply "illegal moves generated by second"? >>And is this number 1 707 964? And on what computer? >> > >Captures/Moves is "LEGAL" moves/unmoves made per second. It is Total legal >captures + Total legal moves / Elapsed time. The invalid moves made/unmade are >not included. I ran this on a Pentium III Xeon 550Mhz machine. Probably your number confirme mine. Since I spoke with you last time, I went to see this position with my special counter. This counter (I described it before) say average number of legal moves for each ply for given position. It calculate and say in the same time average number of legal moves that this part of program generate in one second. Search was done 8 plys deep. AMD 400Mhz. For black: 30 moves average for each ply. 1132k average legal moves generated per second. I forgot to see average NPS that this program also say when it search average number of moves per ply. But I have for normal search indication: 287k. Above search must give around 45% higher number. Should be above 400k. For white: 31 moves as average for each ply. 1100k average number of legal moves generated per second. For normal search NPS is indicated as 339k. For this search must also go beyond 400k. Uniform plys structure produce higher NPS numbers. Your numbers are probably so high because they are illegal. Make and unmake the position don't consume that much time in average program. Even sorting of moves is not time consuming. Generation of moves it is where all the time goes. Our numbers of move generation I see as very close. Leonid. >>>The branching factor looks like it is between 35 and 36 using MinMax. >>>This is what I have found to be documented for the average number of moves >>>for a side. >> >>For this I have special fonction in my program. It do usual search by Brute >>Force but only generate for each ply all its legal moves. This permit constant >>saying of average moves for given position. Have this for 8 and 10 plys deep >>search. >> >>Thanks for response, >>Leonid. >> >>>Larry.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.