[Numpy-discussion] NEP: Random Number Generator Policy

[Robert Kern]

On Sun, Jun 10, 2018 at 5:47 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
> On Sun, Jun 3, 2018 at 9:23 PM, Warren Weckesser <
warren.weckesser at gmail.com> wrote:

>> I suspect many of the tests will be easy to update, so fixing 300 or so
tests does not seem like a monumental task.
>
> It's all not monumental, but it adds up quickly. In addition to changing
tests, one will also need compatibility code when supporting multiple numpy
versions (e.g. scipy when get a copy of RandomStable in
scipy/_lib/_numpy_compat.py).
>
> A quick count of just np.random.seed occurrences with ``$ grep -roh
--include \*.py np.random.seed . | wc -w`` for some packages:
> numpy: 77
> scipy: 462
> matplotlib: 204
> statsmodels: 461
> pymc3: 36
> scikit-image: 63
> scikit-learn: 69
> keras: 46
> pytorch: 0
> tensorflow: 368
> astropy: 24
>
> And note, these are *not* incorrect/broken usages, this is code that
works and has done so for years.

Yes, some of them are incorrect and broken. Failure can be difficult to
detect. This module from keras is particularly problematic:


https://github.com/keras-team/keras-preprocessing/blob/master/keras_preprocessing/image.py

> Conclusion: the current proposal will cause work for the vast majority of
libraries that depends on numpy. The total amount of that work will
certainly not be counted in person-days/weeks, and more likely in years
than months. So I'm not convinced yet that the current proposal is the best
way forward.

The mere usage of np.random.seed() doesn't imply that these packages
actually require stream-compatibility. Some might, for sure, like where
they are used in the unit tests, but that's not what you counted. At best,
these numbers just mean that we can't eliminate np.random.seed() in a new
system right away.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180610/a0d9a37d/attachment.html>