Re: [Numpydiscussion] random and RandomArray
Hi, The Mersenne Twister is available in Python as:
/Python2.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.hiroshimau.ac.jp/~mmat/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: [Numpydiscussion] random and RandomArray To: numpydiscussion@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 _______________________________________________ Numpydiscussion mailing list Numpydiscussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpydiscussion
Bruce Southey wrote:
Hi, The Mersenne Twister is available in Python as:
/Python2.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.hiroshimau.ac.jp/~mmat/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, welltested, and widelyused. 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