[Numpy-discussion] Random number generators.
Charles R Harris
charlesr.harris at gmail.com
Sun Jun 4 15:41:07 CDT 2006
MWC8222 has good distribution properties, it comes from George Marsaglia and
passes all the tests in the Diehard suite. It was also used among
others by Jurgen
Doornik in his investigation of the ziggurat method for random normals and
he didn't turn up any anomalies. Now, I rather like theory behind MT19937,
based as it is on an irreducible polynomial over Z_2 discovered by brute
force search, but it is not the end all and be all of rng's. And yes, I do
like to generate hundreds of millions of random numbers/sec, and yes, I do
do it in c++ and use boost/python as an interface, but that doesn't mean
numpy can't use a speed up now and then. In particular, the ziggurat method
for generating normals is also significantly faster than the polar method in
numpy. Put them together and on X86_64 I think you will get close to a
factor of ten improvement in speed. That isn't to be sniffed at, especially
if you are simulating noisy images and such.
On 6/4/06, Stephan Tolksdorf <st at sigmasquared.net> wrote:
> > MWC8222:
> > nums/sec: 1.12e+08
> > MT19937:
> > nums/sec: 5.41e+07
> > The times for 32 bit binaries is roughly the same. For generating large
> > arrays of random numbers on 64 bit architectures it looks like MWC8222
> > is a winner. So, the question is, is there a good way to make the rng
> > selectable?
> Although there are in general good reasons for having more than one
> random number generator available (and testing one's code with more than
> one generator), performance shouldn't be the deciding concern for
> selecting one. The most important characteristic of a random number
> generator are its distributional properties, e.g. how "uniform" and
> "random" its generated numbers are. There's hardly any generator which
> is faster than the Mersenne Twister _and_ has a better
> equi-distribution. Actually, the MT is so fast that on modern processors
> the contribution of the uniform number generator to most non-trivial
> simulation code is negligible. See www.iro.umontreal.ca/~lecuyer/ for
> good (mathematical) surveys on this topic.
> If you really need that last inch of performance, you should seriously
> think about outsourcing your inner simulation loop to C(++). And by the
> way, there's a good chance that making the rng selectable has a negative
> performance impact on random number generation (at least if the
> generation is done through the same interface and the current
> implementation is sufficiently optimized).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion