[Numpy-discussion] NEP: Random Number Generator Policy
shoyer at gmail.com
Sun Jun 10 23:38:50 EDT 2018
On Sun, Jun 10, 2018 at 8:10 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
> On Sun, Jun 10, 2018 at 5:57 PM, Robert Kern <robert.kern at gmail.com>
>> > 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.
> Well, mere usage has been called an antipattern (also on your behalf),
> plus for scipy over half of the usages do give test failures (Warren's
> quick test). So I'd say that counting usages is a decent proxy for the work
> that has to be done.
Let me suggest another possible concession for backwards compatibility. We
should make a dedicated module, e.g., "numpy.random.stable" that contains
functions implemented as methods on StableRandom. These functions should
include "seed", which is too pervasive to justify removing.
Transitioning to the new module should be as simple as mechanistically
replacing all uses of "numpy.random" with "numpy.random.stable".
This module would add virtually no maintenance overhead, because the
implementations would be entirely contained on StableRandom, and would
simply involve creating a single top-level StableRandom object (like what
is currently done in numpy.random).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion