[Numpy-discussion] in place random generation

Mark P. Miller mpmusu@cc.usu....
Sat Mar 10 11:13:09 CST 2007

Robert:  Just a thought on this topic:

Would it be possible for the Scipy folks to add a new module based 
solely off your old mtrand code (pre-broadcast)?  I have to say that the 
mtrand code from numpy 0.9.8 has some excellent advantages over the core 
python random number generators.

This would allow Scipy to have a pure random number generator, whereas 
numpy could keep its fancier (but slower) array-based random number 

Robert Kern wrote:
> Anne Archibald wrote:
>> On 09/03/07, Robert Kern <robert.kern@gmail.com> wrote:
>>> Mark P. Miller wrote:
>>>> As an aside, are the random number generators from scipy.random the same
>>>> as those for numpy.random?  If not, will those of us who need to just
>>>> use a few random numbers here and there throughout our code (we don't
>>>> need arrays of random numbers or broadcasting abilities) benefit more
>>>> from using those libraries?
>>> scipy.random is not a package. scipy/__init__.py does a "from numpy import *"
>>> and thus pulls in numpy.random.
>> Why does it do this? It makes it a bit confusing (for example, the
>> post above), but presumably it was done for a compelling reason...
> Back when scipy was based on Numeric, scipy provided a slew of new, basic array
> functions (e.g. linspace(), et al.) that have now been folded into numpy. It
> also overrode the math ufuncs with faster variants that would yield nans and
> infs rather than throwing a ZeroDivisionError. The idea was to be able to use
> "scipy" as a replacement for "Numeric".
> I wish we didn't do it today, either, but we are stuck with a lot of legacy code.

More information about the Numpy-discussion mailing list