Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Hash Collision

Author: Russell Reagan

Date: 21:42:49 12/08/02

Go up one level in this thread


On December 07, 2002 at 23:21:11, Robert Hyatt wrote:

>I don't remember the results any longer, but several of us ran some tests years
>ago in a discussion on r.g.c, and found that 32 bits is useless, and that 64
>bits has so few errors they can be ignored.  With recent testing I did that
>suggests that a bad hash collision every 10K nodes has no effect on the final
>score, we seem to be "ok".  :)

Do you think any additional verification would be an improvement? For example,
checking to see if the pseudo-legal moves are the same for the position (maybe
a pseudo-legal moves hash key, or pseudo-pawn moves hash key). It would seem
impossible to have a 64-bit hash key be the same for two different positions,
and their pseudo-legal moves hash key also be the same.

You could generate it at move generation time, and have it ready to go, and you
could use whichever piece sets you wanted. You could even have several keys. One
for (say), rook and bishop moves, another for pawn and queen moves, etc. If the
regular hash key is the same, check to see if the next key is the same, and if
you have several keys, it seems like you could be sure that a position was the
same. I imagine with such a scheme, you might get a single false result in the
entire life of your program.

Would that be too expensive and slow things down too much?



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.