Author: Stuart Cracraft
Date: 14:12:58 07/15/04
Okay so I've been tracking down this annoying bug and ran into the following. In the search from the opening position ending with e4 e5; Qe2 d5; ed Qxd5; Qe5 and likewise ending with e4 e6; Qe2 d5; ed Qxd5; Qxe6 both gave the exact same 64-bit hash key (c1ca9c30) for the final positions after Qd5 and Qxe6, during only a 4 ply search that handed back to the main search after quiescence. But it also gave the same problem if I put the program into force mode and observeed the position hash after the above two move sequences. The 64-bit hash key is calculated after each move xoring out the from and xoring in the new to and handles the usual promotions and captures, etc. and all the inverse for unmakemove. All of that works fine as far as I can see. The same process is used whether for makemove or unmakemove in the main search or in the quiescence search. I am loathe to add another 64-bit key as a match key to be stored additionally within the hash table for use by retrieve() to ensure the position matches due to space it would eat up. Is that my only course of action? I have already inspected the 64-bit hash table of the pieces doing the moving and they are filled with all different values. I've read a lot about how these collisions happen rarely with 64-bit keys and how that would imply this is a bug, and so forth. Tried doing a hardware watchpoint for when the hashkey goes to the above value but in GNU C after doing watch hashkey == 0xc1ca9c30, it never got tripped strangely. Stuart
This page took 0.01 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.