[Numpy-discussion] Re: random number facilities in numarray and main Python libs
perry at stsci.edu
Tue Sep 28 12:52:18 CDT 2004
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 at ucsd.edu>
>>> Faheem Mitha wrote:
>>>> 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
>>> 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
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
would guess that it should) that would be great, and should not cause
schism since its the same code (aside from the setup.py). In a month or
may be possible to put it only on scipy, but I don't think it is
to make that so now, particularly if there is only one version of the C
More information about the Numpy-discussion