[Numpy-discussion] NEP: Random Number Generator Policy

[Robert Kern]

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
>> 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
>> become
>> increasingly noisy over time.  Bugs in the current state of the code will
>> *not*
>> be fixed if fixing them would impact the stream.  However, if changes in
>> the
>> rest of ``numpy`` would break something in the ``RandomState`` code, we
>> will
>> 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.

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