random number facilities in numarray and main Python libs
Dear People, I recently encountered a strange problem when writing some Python using random number code. I tried setting the seed at top level, but I was still get random results. I submitted a bug report, and had my error explained to me. I had run into this problem several times, and I think some mental block had prevented me from seeing the source of the problem. Part of the reason is that I had previously been using R, and everyone uses the same random number generator facilities. Are the random number facilities provided by numarray.random_array superior to those provided to those provided by the random module in the Python library? They certainly seem more extensive, and I like the interface better. If so, why not replace the random module by the equivalent functionality from numarray.random_array, and have everyone use the same random number generator? Or is this impossible for practical reasons? By the way, what is the name of the pseudo-random number generator being used? I see that the code is in Packages/RandomArray2/Src, but could not see where the name of the generator is mentioned. Faheem.
Faheem Mitha wrote: [snip]
Are the random number facilities provided by numarray.random_array superior to those provided to those provided by the random module in the Python library? They certainly seem more extensive, and I like the interface better.
If so, why not replace the random module by the equivalent functionality from numarray.random_array, and have everyone use the same random number generator? Or is this impossible for practical reasons?
numarray.random_array can generate arrays full of random numbers. Standard Python's random does not and will not until numarray is part of the standard library. Standard Python's random also uses the Mersenne Twister algorithm which is, by most accounts, superior to RANLIB's algorithm, so I for one would object to replacing it with numarray's code. :-) I do intend to implement the Mersenne Twister algorithm for SciPy's PRNG facilities (on some unspecified weekend). I will also try to code something up for numarray, too.
By the way, what is the name of the pseudo-random number generator being used? I see that the code is in Packages/RandomArray2/Src, but could not see where the name of the generator is mentioned.
<URL:http://orion.math.iastate.edu/burkardt/c_src/ranlib/ranlib_base.txt> documents the base algorithm.
Faheem.
-- 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
On Tue, 07 Sep 2004 16:35:11 -0700, Robert Kern <rkern@ucsd.edu> wrote:
Faheem Mitha wrote: [snip]
Are the random number facilities provided by numarray.random_array superior to those provided to those provided by the random module in the Python library? They certainly seem more extensive, and I like the interface better.
If so, why not replace the random module by the equivalent functionality from numarray.random_array, and have everyone use the same random number generator? Or is this impossible for practical reasons?
numarray.random_array can generate arrays full of random numbers. Standard Python's random does not and will not until numarray is part of the standard library. Standard Python's random also uses the Mersenne Twister algorithm which is, by most accounts, superior to RANLIB's algorithm, so I for one would object to replacing it with numarray's code. :-)
I do intend to implement the Mersenne Twister algorithm for SciPy's PRNG facilities (on some unspecified weekend). I will also try to code something up for numarray, too.
Does SciPy have its own random num facilities too? It would easier to just consolidate all these efforts, I would have thought.
By the way, what is the name of the pseudo-random number generator being used? I see that the code is in Packages/RandomArray2/Src, but could not see where the name of the generator is mentioned.
<URL:http://orion.math.iastate.edu/burkardt/c_src/ranlib/ranlib_base.txt> documents the base algorithm.
Thanks for the reference. Faheem.
Faheem Mitha wrote:
On Tue, 07 Sep 2004 16:35:11 -0700, Robert Kern <rkern@ucsd.edu> wrote:
Faheem Mitha wrote: [snip]
Are the random number facilities provided by numarray.random_array superior to those provided to those provided by the random module in the Python library? They certainly seem more extensive, and I like the interface better.
If so, why not replace the random module by the equivalent functionality from numarray.random_array, and have everyone use the same random number generator? Or is this impossible for practical reasons?
numarray.random_array can generate arrays full of random numbers. Standard Python's random does not and will not until numarray is part of the standard library. Standard Python's random also uses the Mersenne Twister algorithm which is, by most accounts, superior to RANLIB's algorithm, so I for one would object to replacing it with numarray's code. :-)
I do intend to implement the Mersenne Twister algorithm for SciPy's PRNG facilities (on some unspecified weekend). I will also try to code something up for numarray, too.
Does SciPy have its own random num facilities too? It would easier to just consolidate all these efforts, I would have thought.
I would agree, which is why I don't like the current move to put all kinds of processing facility into numarray. It is creating two parallel efforts and causing a split in the community. The purpose of SciPy was to collect scientific algorithms together (scipy's random number facilities are borrowed and enhanced from Numeric --- same place numarray comes from). -Travis O.
On Sep 28, 2004, at 2:04 PM, Travis Oliphant wrote:
Faheem Mitha wrote:
On Tue, 07 Sep 2004 16:35:11 -0700, Robert Kern <rkern@ucsd.edu> wrote:
Faheem Mitha wrote: [snip]
Are the random number facilities provided by numarray.random_array superior to those provided to those provided by the random module in the Python library? They certainly seem more extensive, and I like the interface better.
If so, why not replace the random module by the equivalent functionality from numarray.random_array, and have everyone use the same random number generator? Or is this impossible for practical reasons?
numarray.random_array can generate arrays full of random numbers. Standard Python's random does not and will not until numarray is part of the standard library. Standard Python's random also uses the Mersenne Twister algorithm which is, by most accounts, superior to RANLIB's algorithm, so I for one would object to replacing it with numarray's code. :-)
I do intend to implement the Mersenne Twister algorithm for SciPy's PRNG facilities (on some unspecified weekend). I will also try to code something up for numarray, too.
Does SciPy have its own random num facilities too? It would easier to just consolidate all these efforts, I would have thought.
I would agree, which is why I don't like the current move to put all kinds of processing facility into numarray. It is creating two parallel efforts and causing a split in the community.
I guess as long as the work was done using the common api then I don't really see it as a parallel effort. At the moment scipy doesn't support numarray (we are working on that now, starting with adding n-ary ufunc support) so making it work only with scipy may not satisfy the more immediate needs of those that would like to use it numarray. If the code can be written to support both (using some #ifdef's, would guess that it should) that would be great, and should not cause any great schism since its the same code (aside from the setup.py). In a month or two, it may be possible to put it only on scipy, but I don't think it is necessary to make that so now, particularly if there is only one version of the C code. Perry
participants (4)
-
Faheem Mitha -
Perry Greenfield -
Robert Kern -
Travis Oliphant