Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Hashkey collisions (typical numbers)

Author: Sune Fischer

Date: 07:21:38 04/07/04

Go up one level in this thread


>>>
>>>your number is much too high. a good estimate for the hash collision probability
>>>is 1/sqrt(hashkey_range); which in your case comes out as 2^-32 or about
>>>somewhere around one in a billion...
>>
>>Not at all. It's way less than that with 64 bits Zobrist.
>
>i never took the trouble to measure it, but the math is rather straightforward.
>so i'd say you have an implementation bug too ;-)
>
>cheers
>  martin

Not necessarily. If he has a very large hash table with more than 2^32 entries
the probability of a collision increases rapidly with 64 bit keys.

It's the birthday problem, the more kids you have in the class the bigger the
chance of two birthsdays falling on the same date.

If you have a only a single hash entry the chance will be 2^64 of a collision,
assuming perfect randomness.

-S.
>>I measured it with 460 processors at a supercomputer with a shared hashtable and
>>had major problems to get at 7 million nodes a second stored, some
>>errors/collissions.
>>
>>>make sure you're not doing anything wrong with the hashkey updating like
>>>suggested by others - compare with a computed-from-scratch key. also make sure
>>>that your nullmove doesn't break your hashkey. and just to be sure, check that
>>>you haven't got 32-bit numbers instead of 64 bit numbers by accident...
>>>cheers
>>>  martin
>>
>>I'm sure it was some implementation bug with Renze.



This page took 0.01 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.