Author: martin fierz
Date: 13:02:23 10/30/03
Go up one level in this thread
On October 30, 2003 at 11:13:32, Robert Hyatt wrote:
>On October 29, 2003 at 11:31:18, martin fierz wrote:
>
>>On October 29, 2003 at 09:32:37, Gerd Isenberg wrote:
>>
>>>On October 29, 2003 at 07:00:56, martin fierz wrote:
>>>
>>>>On October 28, 2003 at 15:01:40, Gerd Isenberg wrote:
>>>>
>>>>>On October 28, 2003 at 14:50:35, Martin Schreiber wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>For my hash tables I need 64 bit random numbers, but I don't know the source
>>>>>>code.
>>>>>>I use Dev-C++.
>>>>>>Can anybody help me?
>>>>>>
>>>>>>Martin
>>>>>
>>>>>This simple one works quite well
>>>>>
>>>>>UINT32 HashRand32()
>>>>>{
>>>>> static UINT32 r = 0;
>>>>> return (r = 1664525L*r + 1013904223L);
>>>>>}
>>>>>
>>>>>...
>>>>>hashval = HashRand32();
>>>>>hashval = (hashval << 32) | HashRand32();
>>>>
>>>>i use a similar concatenation of random numbers generated with the C rand()
>>>>function.
>>>>
>>>>i have never believed all the stuff about "bad" or "good" random numbers for
>>>>hashing purposes (of course, for other things it's different...). i also don't
>>>>believe this "hamming distance" stuff. i'd be very surprised if any of this made
>>>>any difference in practice. has anybody ever tested this?
>>>>
>>>>cheers
>>>> martin
>>>
>>>
>>>Hi Martin,
>>>
>>>i'm not an expert in pseudo random number generators.
>>>I never tried C-rand() so far, because it may vary from system to system and i
>>>want deterministic numbers independent from compiler or os. I looked for min and
>>>average hamming distance, but i have no idea whether a min hamming distance of
>>>let say 16 does necessarily imply higher collision rate as 30.
>>>I store the whole 64 bit signature inside my hash structure - and even look for
>>>validity of the stored move.
>>>
>>>Cheers,
>>>Gerd
>>
>>hi gerd,
>>
>>there was once a discussion about hamming distance and good random numbers, and
>>IIRC there was also a "good" function for getting one's random numbers. i
>>compared that with mine, which was supposed to be "bad" and couldn't find any
>>difference in practice... that's why i don't believe this stuff any more!
>>
>>cheers
>> martin
>
>
>The main point is to use a known RNG, if you use different machines. IE I
>originally grabbed my RNG to include in Cray Blitz, so that I could make a
>book that would work, even if the Cray compiler/library guys changed their
>RNG code (which they did from time to time). It was also useful in that it
>allowed me to run on my vax and compare node counts to the Cray, without having
>minor differences caused by different hash signatures producing different
>overwrite/reuse results.
this is of course true; in checkers you need even less numbers because there are
only 2 piece types and 32 squares, i simply hardcoded them into my program :-)
>you only need 768 64 bit numbers for the 12 possible square contents times
>the 64 possible squares. Plus maybe a few more for castling and en passant,
>depending on how you handle those. Any RNG will most likely produce 1500
>values that are random and uniform. There are many RNGs that have short
>periods of course, but not a period of 1500 or less. That's all we need,
>and I agree that most of this hyperbole about randomness, and hamming
>distance is not so important, although RNGs with a hamming distance of zero
>ought to be avoided. :)
yeah, zero is just a bit too little. i always thought this randomness + hamming
distance thing was overrated, but after hearing about your experiments with
false positives i'm certain now :-)
cheers
martin
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.