Author: Daniel Clausen
Date: 14:16:54 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. > >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 Do you have any kind of 'verifyBoardStructure' function? I have one which - when called - verifies all the things which are updated incrementally by calculating it from scratch again and comparing. Sargon
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.