Author: Stuart Cracraft
Date: 21:47:48 07/15/04
Go up one level in this thread
On July 15, 2004 at 18:04:02, Robert Hyatt 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
>>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???
My printf("%x"..) must not be printing full 64 bits.
I'll have to shift the upper 32 and do two printf's...
>
>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..
It was buggy. I made the stupid move to make zob[2][6][64] rather
than zob[2][12][64]. The code was infested with that alone.
Other huge gaps included using a mixture of unsigned long long and
signed long long and not having all the former.
There were others... and are still some. Hard stuff.
>
>
>>
>>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.