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

[Gunnar Farneback]

Arend wrote:
> 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.

I think it's a bit misleading to call it a second hash value. For all
practical purposes this is just one Zobrist hash value but with more
bits.

So the question is whether to use an M bit Zobrist hash plus a full
board as fallback or only an N bit Zobrist hash. The problem with the
latter is that a hash collision would be undetectable and might cause
mysterious mistakes or even assertion failures. Essentially it's a
tradeoff between security and memory usage of course.

I think a 64 bit hash would be safe enough in practice, especially
since we have other sources of mysterious mistakes these days
(persistent caches), but we should leave the possibility to toggle
between the modes. I definitely don't think we should change the
default behavior before 3.2.

/Gunnar