Author: Vincent Diepeveen
Date: 07:03:27 08/17/02
Go up one level in this thread
On August 16, 2002 at 23:26:08, James Swafford wrote:
In general combining 2 integers of 32 bits to a 64 bits
integer is a very bad idea with regard to random numbers.
You will see that this gives in general a multilineair relation.
Some years ago i posted about this here and the results were
very bad. Without exception random move generators which give 32
bits numbers are simply too weak to use for Zobrist hashing.
Pretty good results i had with RanRot generators, which basically
also work on a fibonacci bla bla heap, and i could use the generator
perfectly for some software which needed loads of random numbers.
Yet the advantage of the
RanRot is that it is 64 bits and a kind of 'enigma' bit rotating idea
where things get rotated in a pretty effective way,
so in short working quite better than
a 32 bits generator.
No big surprises there of course.
In general 64 bits random
numbers are pretty ok to use, completely in contradiction to 32
bits numbers, even when using the same generator!
I also tried 48 bits numbers, this was in a time that i wasn't convinced
till my last bone that one needs at least 64 bits numbers.
Note to not take any risk i have not only generated 12 x 64 + 64 numbers
(for en passant and castling all together you need at most 64 numbers
not so much as you post, can get them from the same array because for
en passant you hash a number from a diff square than for castling), but
then put them in a special file and when it was around 5 AM i have then
turned on the capslock and 'overwrite' mode and have hacked into
my numbers.
Also i store 64 bits AND the side to move (so 65 bits in total) at least
to be sure that i use the full hashkey.
Sincethen i have even at a search of a few billion nodes *zero* problems.
Obviously i measured that with an extra hashtable having more information
regarding a position. So basically the only thing i haven't been able
to do is measure with a HUGE hashtable and then searching a few
billion nodes.
Such tests took pretty long if you realize that DIEP, especially at hardware
from a few years ago, got very little nodes a second :)
Such a test now would only be a few hours...
I know from several who have done similar test too. I can advice you to
do such a test, even if it was to be only sure that you don't have bad
luck.
Just take the openings position and search 22 ply there. That's 11 full
moves from the start. If your move ordering isn't good there, than
take something like 1.e4,e5 and search from there. In general positions
with less pieces than all of them is a bad idea to measure how good your
random numbers are.
>I'm in the process of tracking down some hashing problems, and
>I'm starting with my Zobrist keys. For each piece (i.e. bp, wp,
>wr, ...) I have 64 keys. I have 65 keys for "ep square", two
>for "player to move", 16 for castling rights. All keys are 64 bits.
>
>I just did a test to find the minimum hamming distance among
>all keys, and it was 14 bits. That seems a bit low.
>
>I think the way I'm doing 64 bit random number generation sucks.
>Here it is:
>
>Bitmap RandomBitmap(void)
>{
> Bitmap r1,r2;
>
> r1=Random32();
> r2=Random32();
>
> return ((r1<<32)|r2);
>}
>
>
>Ok, someone please confirm that this sucks and tell me a better
>way. :)
>
>I'm also interested in hearing what others are getting for min
>hamming distance between keys.
>
>--
>James
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.