[Numpy-discussion] Random number generators. (original) (raw)

Charles R Harris charlesr.harris at gmail.com
Sun Jun 4 16:41:07 EDT 2006

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 <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). Regards, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20060604/679f9962/attachment-0001.html>

More information about the NumPy-Discussion mailing list