[Numpy-discussion] NEP: Random Number Generator Policy
robert.kern at gmail.com
Sun Jun 3 20:37:45 EDT 2018
On Sun, Jun 3, 2018 at 5:23 PM Stephan Hoyer <shoyer at gmail.com> wrote:
> 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
>> subsystem alongside it. This allows anyone who has been relying on our
>> 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
> explicitly set?
> 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.
Well, *I* propose `AttributeError`, myself…
> I suppose this will be your next NEP :).
I deliberately left it out of this one as it may, depending on our choices,
impinge upon the design of the new PRNG subsystem, which I declared out of
scope for this NEP. I have ideas (besides the glib "Let them eat
AttributeErrors!"), and now that I think more about it, that does seem like
it might be in scope just like the discussion of freezing RandomState and
StableRandom are. But I think I'd like to hold that thought a little bit
and get a little more screaming^Wfeedback on the core proposal first. I'll
return to this in a few days if not sooner.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion