Author: Ricardo Gibert
Date: 23:06:18 07/11/03
Go up one level in this thread
On July 11, 2003 at 22:39:35, Tom Likens wrote: >On July 11, 2003 at 18:06:56, Ricardo Gibert wrote: > >>On July 11, 2003 at 17:50:21, Ricardo Gibert wrote: >> >>>On July 11, 2003 at 17:23:10, Tom Likens wrote: >>> >>>[snip] >>> >>>>I probably haven't solved your problem but of course these things >>>>are insidious. Also I could easily be misinterpreting some of >>>>your code, if so I apologize. >>>> >>>>Some general advice, you probably should convert to 64-bit hash >>>>keys to reduce the chance of collisions. >>> >>> >>>Actually, every program should allow this to be configurable. For instance, an >>>8-bit hash can be useful in debugging and a 32-bit hash is something interesting >>>and not known for certain to be a bad idea. > >This is a valid point. It's intriguing that even though a 32-bit hash >key *will* result in collisions, the real question is wheter those >collisions will actually propagate back up the tree and cause the >program to select an inferior move. > >>Just want to add that a 256-bit hash key can be useful for debugging too. By >>contrasting 64-bit with 256-bit, one might conclude that the quality of the >>random numbers is wanting. > >I'm not sure I follow this. I'm guessing (without actually testing it) >that the difference in the number of collisions between a 64-bit hash >key and a 256-bit hash key would be vanishingly small for the typical >search trees that modern programs explore. Is there some other advantage >of a 256-bit hash key over a 64-bit key that I'm missing? Yes. When the difference is *not* vanishingly small, then you have discovered your program has a bug. This is why it might be useful for debugging. > >regards, >--tom
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.