Re: Hash position storing (Re: [gnugo-devel] The late phase of the release cycle)

[Daniel Bump]

Arend wrote:

> I have an issue that should be answered well before 3.2.
> 
> While I was browsing through chess web pages for minimax optimizations I
> also read the following on Zobrist hashing: apparently, chess engines, when
> they have found a position with matching hash value in a cache table lookup,
> they do the following: instead of exactly comparing the actual position
> with the stored position, they just compare a 2nd computed hash value.
> 
> The theory behind that is that a "double hash collision" is so unlikely
> that it is better to allow for it and instead save cache memory (and a
> little time) -- a 2nd hash value needs considerably less memory than a
> fullboard position.

This sounds like definitely a post 3.2 issue. Whether or not it is 
a good change is something that we can try and decide, but the time to
make fundamental changes like this is early in the release cycle, not late.

Dan