[Numpy-discussion] NEP: Random Number Generator Policy
shoyer at gmail.com
Sun Jun 3 20:18:38 EDT 2018
On Sat, Jun 2, 2018 at 12:06 PM Robert Kern <robert.kern at gmail.com> wrote:
> We propose first freezing ``RandomState`` as it is and developing a new RNG
> subsystem alongside it. This allows anyone who has been relying on our old
> stream-compatibility guarantee to have plenty of time to migrate.
> ``RandomState`` will be considered deprecated, but with a long deprecation
> cycle, at least a few years. Deprecation warnings will start silent but
> increasingly noisy over time. Bugs in the current state of the code will
> be fixed if fixing them would impact the stream. However, if changes in
> rest of ``numpy`` would break something in the ``RandomState`` code, we
> fix ``RandomState`` to continue working (for example, some change in the
> C API). No new features will be added to ``RandomState``. Users should
> migrate to the new subsystem as they are able to.
Robert, thanks for this proposal. I think it makes a lot of sense and will
help maintain the long-term viability of numpy.random.
The main clarification I would like to see addressed is what "freezing
RandomState" means for top level functions in numpy.random. I think we
could safely swap out the underlying implementation if numpy.random.seed()
is not explicitly called, but how would we handle cases where a seed is
You and I both agree that this is an anti-pattern for numpy.random, but
certainly there is plenty of code that relies on the stability of random
numbers when seeds are set by np.random.seed(). Similar to the case for
RandomState, we would presumably need to start issuing warnings when seed()
is explicitly called, which begs the question of what (if anything) we
propose to replace seed() with. I suppose this will be your next NEP :).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion