Author: Robert Hyatt
Date: 14:59:17 07/09/02
I have been running some tests after prompting by Bruce, and the results have been interesting. The question posed by him was "how many hash collisions (signatures match but positions do not) can we tolerate in a search without having serious problems?" I did the following: I made my HashProbe() routine use the node counter, and every N nodes, I would "match" a hash entry even if the signatures were not the same, simulating a collision. I got all the way down to a collision every 1000 nodes without seeing even a score change at the root, which was surprising. I would like to ask others to try this as well. It only adds a couple of lines to your HashProbe() code. I started at one "collision" every 100K nodes, but that did nothing. Then one every 10K. And finally one every 1K. This seems surprising to me. I ran several positions, with and without the "collision problem" and compared my logfile output. Scores did not change at all. I used tactical positions like Kopec22, opening positions, and even the classic fine #70. Seems that the search is far more resistant to such errors than anybody has thought previously. It would be interesting to see if this is just a result of Crafty, or if it holds for others. Particularly for someone that hashes in the q-search, which I do not do... Note that I did not false match every N calls to HashProbe() rather I false matched on the next call to HashProbe() after having searched N nodes since the previous call. Sometimes this would be less frequently than once per 1000 nodes obviously, since I could burn several thousand nodes in the q-search and not do another false match until I get back out of that mess and back into the normal non-qsearch part.
This page took 0.02 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.