[Numpy-discussion] Moving NumPy's PRNG Forward

[Stephan Hoyer]

On Fri, Jan 19, 2018 at 6:57 AM Robert Kern <robert.kern at gmail.com> wrote:

> As an alternative, we may also want to leave `np.random.RandomState`
> entirely fixed in place as deprecated legacy code that is never updated.
> This would allow current unit tests that depend on the stream-compatibility
> that we previously promised to still pass until they decide to update.
> Development would move to a different class hierarchy with new names.
>

I like this alternative, but I would hesitate to call it "deprecated".
Users who care about exact reproducibility across NumPy versions (e.g., for
testing) are probably less concerned about performance, and could continue
to use it.

New random number generator classes could implement their own guarantees
about compatibility across their methods.

I am personally not at all interested in preserving any stream
> compatibility for the `numpy.random.*` aliases or letting the user swap out
> the core PRNG for the global PRNG that underlies them. `np.random.seed()`
> should be discouraged (if not outright deprecated) in favor of explicitly
> passing around instances.
>

I agree that np.random.seed() should be discouraged, but it feels very late
in NumPy's development to remove it.

If we do alter the random number streams for numpy.random.*, it seems that
we should probably issue a warning (at least for a several major versions)
whenever numpy.random.seed() is called. This could get pretty noisy. I
guess that's all the more incentive to switch to random state objects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180119/b58ff872/attachment-0001.html>