Author: Stuart Cracraft
Date: 22:04:13 07/15/04
Go up one level in this thread
On July 15, 2004 at 17:56:36, Dieter Buerssner wrote:
>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
>
>This is a 32 bit value, not a 64-bit value (it is extremely unlikely, that all
>32 upper bits are zero).
>
>>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.
>
>Doing the inverse in unmakemove is probably too much effort. Just store the old
>hashkey in makemove, and retrieve it in unmakemove in some (global) data.
>
Thanks -- I have implemented your suggestion.
>>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.
>
>I typically add something like
>
> if (hashkey == somenumber)
> printf("found\n");
>
>and add a breakpoint to the printf line, which might actually print more info,
>like a node count. Then add another if (nodes == thatnumber) printf ...
>
>So, you eventually will get to the right point in debug mode and can single step
>it.
>
>Regards,
>Dieter
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.