I've made a stab at replacing the RANLIB-based PRNG that we currently use in scipy.stats with the superior-in-every-conceivable-way Mersenne Twister. It's currently a separate module, and it has only been tested on Numeric 24.0b2 not the new scipy.base, but it should be able to be almost a drop-in replacement for the module that's currently there. The only distribution I haven't covered is the multivariate normal because I didn't really feel like doing linear algebra in C. But that's easy enough to do at the Python level. The core Mersenne Twister routines come from Jean-Sebastien Roy's RandomKit. Thank you, JS! http://www.jeannot.org/~js/code/index.en.html I would appreciate people putting it through its paces. I've done visual checking of the distributions via Q-Q plots; the script is included as the tests/qq.py and requires matplotlib. I haven't implemented real unit tests via K-S significance tests or Kullback-Leibler distance, but I guess I ought to eventually. The sampling algorithms were implemented from scratch by me from the original literature, so if you see funky numbers, it's probably my fault. AFAICT right now, the numbers are no funkier than those produced by RANLIB. http://cheeseshop.python.org/pypi/mtrand/0.1 -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Robert> I've made a stab at replacing the RANLIB-based PRNG that we Robert> currently use in scipy.stats with the superior-in-every- Robert> conceivable-way Mersenne Twister. Python has used the Mersenne Twister as the basis for its random number generator since at least 2.2. Is there a reason to incorporate it separately? -- Skip Montanaro skip@pobox.com
skip@pobox.com wrote:
Robert> I've made a stab at replacing the RANLIB-based PRNG that we Robert> currently use in scipy.stats with the superior-in-every- Robert> conceivable-way Mersenne Twister.
Python has used the Mersenne Twister as the basis for its random number generator since at least 2.2. Is there a reason to incorporate it separately?
Yes! We need to get lots of random numbers stuffed into arrays on the C level. AFAICT, _random doesn't expose a C API. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Robert> AFAICT, _random doesn't expose a C API. It shouldn't be hard to add. Take a look at how it's done for the datetime module (PyDateTime_CAPI struct, PyDateTime_IMPORT macro, etc). Skip
skip@pobox.com wrote:
Robert> AFAICT, _random doesn't expose a C API.
It shouldn't be hard to add. Take a look at how it's done for the datetime module (PyDateTime_CAPI struct, PyDateTime_IMPORT macro, etc).
Sure, and I might do just that later. However, the PRNG in scipy really needs to be updated before Python 2.5 will be released or widely adopted. In any case, the amount of code duplication is small, just the MT19937 algorithm and initialization code which is tiny and from the same reference implementation. I don't think anyone would derive much benefit from our using the exported version. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
participants (2)
-
Robert Kern -
skip＠pobox.com