TalkChess.com

search a fixed number of nodes, record the results. Make any change to the program you want. Search a fixed number of nodes and the results are absolutely useless to compare with the first run. Is that hard to understand given the data I provided above? What is hard to understand is why the results...

Note that my original testing was done when I was locking the hash table for each lookup/store, prior to adding the lockless hash from Cray Blitz. So there I was locking a _bunch_ of times per second and mutex was horrible. If you already have the lock in another thread, you block in the current thr...

search a fixed number of nodes, record the results. Make any change to the program you want. Search a fixed number of nodes and the results are absolutely useless to compare with the first run. Is that hard to understand given the data I provided above? What is hard to understand is why the results...

aha. Yes that bug is present, always has been, and I did not consider it worth spending a lot of time on...

There's more than enough errors in the q-search already. I doubt this produces a measurable effect.

Hi Les, Maybe Rybka is using piece lists combined with bitboard. As what Bob has said, it is true that when you flip a position, the move ordering will also change, resulting to varying time to find the solution, that is if it is a bitboard only engine. There is also a possibility that the eval val...

Hi Bob, What I was curious about was the significant difference in the number of seconds it took depending on which reflection you were working on. Some of the factors were very much different certainly when I compared it to Rybka ie. For reflections Rybka's times across the 4 reflections for the e...

I don't see how this observation in anyway can be interpreted as a drawback of the fixed-nr-of-nodes testing method. IMO you would get exactly the same variability if you would compare testing at 20 sec per move vs 20.01 sec per move. This observation is simply based on the central limit theorem of...

This estimate is for the same (32-bit) binary. For 64-bit you get an extra acceleration, which of course strongly depends on how much 64-bit arithmetic you do compared to 32-bit stuff. For the 64-bit stuff itself it could be more than a factor 2. Thanks, that sounds a lot better! Apparently my prog...

yes. In fact, crafty has commands "flip" and "flop" to do that to the current position. "evtest" takes a FEN suite and does the sanity test using those commands. I ran all 4. all four reported a mate in 6. the scores were +2.18 and -2.18, + when it was black to move, - when it was white to move. So...

Yes, for this reason testing at a fixed number of nodes and recording the ime, rather than fixing the time, seems preferable. But of course you cannot get rid of the randomness induced by SMP that way. For this reason I still want to implement the tree comparison idea I proposed here lately. This w...