[computer-go] C++ random numbers

[Don Dailey]

In Lazarus I use the Mersenne Twister.   It's a high performance very
high quality random number generator and I trust it more than the
library routines (which are probably very good nowadays in GCC.)

The source code is freely available on the web and it's small.   To get
64 bit number just append them together with 32 bit shift or do a union.
Make up a simple little test to make sure you are getting all the bits
correctly.   

Be very careful about using 31 bit random numbers, you will be missing 2
bits if you append them together unless you use 3 numbers to compose 1
64 bit number.


Here is some c++ code for the mersenne twister.

http://www.bedaux.net/mtrand/


Here is another interesting page on random numbers - you may be able to
turn one of these into a 64 bit random number:

http://www.lns.cornell.edu/spr/1999-01/msg0014148.html


- Don



On Wed, 2006-08-09 at 08:27 +0900, Darren Cook wrote:
> > Okay, next question: how do I generate a random 64-bit unsigned integer?
> 
> Here is the code I have in my zobrist class:
> 
> srand48(seed);
> unsigned int v1,v2;
> for(...){
>     v1=static_cast<unsigned int>(mrand48());
>     v2=static_cast<unsigned int>(mrand48());
>     //Combine v1 and v2 into a 64 bit int
>     ...
>     }
> 
> 
> I had this comment in the code:
> 
> mrand48() returns a number between -2^31 and +2^31. This
> is then cast to an unsigned int. The alternatives
> don't seem to give the full 32 bit number.
> I couldn't understand what to do with the Boost.Random functions.
> 
> 
> mrand48 may be linux-only.
> 
> If you want to try the boost functions:
>    http://www.boost.org/libs/random/index.html
> 
> Darren
> 
> P.S. In my zobrist code I actually store as 2 sets of 32-bit numbers
> rather than a 64-bit int. I have the following comment, and I'm
> wondering what other people think about it (there was a big discussion
> about generating zobrist numbers a year or so ago, but I didn't fully
> understand it!):
> 
> The checks I do for repeated numbers are actually stricter than if using
> a 64 bit integer, as it requires both high and low halves to
> be unique. I suspect this is good (less chance of two different
> positions having the same hash code), but otherwise it makes no difference.
> If it was good then it'd be worth generating 16 bit numbers and check
> their uniqueness, then combining them to make the 32 bit numbers.
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/