Re: Re: random number facilities in numarray and main Python libs

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@xxxxxxxx> 
> > 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 



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl