[Numpy-discussion] in place random generation
Mark P. Miller
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 <firstname.lastname@example.org> 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