Re: [Numpy-discussion] random and RandomArray
Hi, The Mersenne Twister is available in Python as:
/Python-2.4/Modules/_randommodule.c
This file contains the outdated information: "The code in this module was based on a download from: http://www.math.keio.ac.jp/~matumoto/MT2002/emt19937ar.html"
The redirected link is titled: Mersenne Twister with improved initialization http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html
A brief look at randlib() suggests that it is written so that different uniform generators could be used. Could randf() be rewritten to have the default (current status) function and a second that just to link to the random module library to use the Mersenne Twister?
Okay, I do know it is not that easy (the seed code would also need to change so account for which generator is being used) but may be sufficient.
Regards Bruce
---- Original message ----
Date: Wed, 16 Feb 2005 20:05:09 -0800 From: Robert Kern rkern@ucsd.edu Subject: Re: [Numpy-discussion] random and RandomArray To: numpy-discussion@lists.sourceforge.net
Bruce Southey wrote:
Hi, I was browsing through some of the code and realized that certain random
number
generators occur in both the Python random module and RandomArray.
The random module uses C code to get a scalar uniform random number that is modified in Python by other generators to get random numbers from other distributions. In RandomArray everything is done in the C code - obviously
this
is way faster especially for arrays.
In the long term, would it make sense to get use the same random number generators in both random and RandomArray?
I think that it is certainly feasible and desirable that when/if a multiarray object enters the standard library that the standard random module be extended to produce arrays as well.
I don't think it's terribly worthwhile to hack the random module to expose its PRNG so that we use it's implementation without duplicating code. I think the result will be quite fragile, and won't be useful until Python 2.5.
I do think it would be extremely worthwhile to implement the Mersenne Twister for numarray/scipy. I promised some time ago to look into this, but I have not gotten around to it, unfortunately.
-- 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
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Bruce Southey wrote:
Hi, The Mersenne Twister is available in Python as:
/Python-2.4/Modules/_randommodule.c
This file contains the outdated information: "The code in this module was based on a download from: http://www.math.keio.ac.jp/~matumoto/MT2002/emt19937ar.html"
The redirected link is titled: Mersenne Twister with improved initialization http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html
A brief look at randlib() suggests that it is written so that different uniform generators could be used. Could randf() be rewritten to have the default (current status) function and a second that just to link to the random module library to use the Mersenne Twister?
Okay, I do know it is not that easy (the seed code would also need to change so account for which generator is being used) but may be sufficient.
All the functions from _randommodule.c that we would need to use are declared static. I'm fairly sure this precludes trying to "link" to _randommodule.so to use these functions. The standard way to do such a thing would be for _randommodule.c to expose function pointers as PyCObjects, but that would require modification of _randommodule.c.
The path of least resistence is to just duplicate the code. It's short, clean, well-tested, and widely-used. It should not present a real maintenance problem. Certainly no more of one trying to share the implementation with _randommodule.
participants (2)
-
Bruce Southey -
Robert Kern