Stephen,

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 <[EMAIL PROTECTED]> 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).

Regards,
   Stephan

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Reply via email to