Re: [computer-go] Re: Sharing Secrets

["Frank de Groot" <frank@xxxxxxxxxxxxx>]

---- Original Message ----- 
From: "John Tromp" <John.Tromp@xxxxxxxxxxxxxxxxx>

> Still, the best solution is not to have tricky ways of handling 
> collisions,
> but to avoid them in the first place. Yes, that means taking care to use
> a good generator. Page likes
We are slowly getting somewhere :)

Your reply shows that indeed I am right in assuming that programmers 
generally haven't got the slightest clue about good Zobrist hashing (not to 
attack you personally, it simply is virtually unknown also Chess programmers 
hate to talk about it because it is the most important part of their hasher)

I never claimed to have a fancy way of avoiding collisions.
In fact, I do not have any tricky re-hashing scheme or any other 
inconvenient method of getting the very best distribution.

I said that random generators suck.
That did not imply that that the solution is a "perfect" random generator.
Even a "perfect" random generator will give piss-poor performance for a 
64-bit Z-hasher. So, herewith I have basically disclosed part of the 
"secret": DO NOT, UNDER ANY CIRCUMSTANCES, USE RANDOM VALUES AS HASH KEYS. 
Never ever. Not even when you use white noise from a resistor or diode. It 
simply gives sub-par performance.

Now, my "secret" lies in the fact that I have found an improvement to the 
hard-to-find accepted solution to the fact that random values suck as 
Zobrist hash keys. So, there is a solution to the big problem of random 
values as hash keys, there are in fact several "solutions", and even the 
best published one is still sub-par.

And, BTW, a 1::65556 chance of collision would be terrible in many cases.
When searching millions of tree nodes and a hash collision can mean the 
difference between pruning or not, you'll find such a hasher unacceptable. 
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/