Author: Robert Hyatt
Date: 15:04:02 07/15/04
Go up one level in this thread
On July 15, 2004 at 17:12:58, Stuart Cracraft wrote: >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. I don't follow. the number you gave is _not_ 64 bits. It is 32 bits long. Is that really the hash signature with the upper 32 bits == 0??? First point is that it would appear that the Zobrist number for pawn on e3 and on e4 are identical. That should not be the case. Check the random numbers for pawns on those two squares. They'd better be different. If they are, then your next step is to debug your signature update code.. > >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. Probably as that is not a 64 bit value. :) > >Stuart
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.