<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Jun 3, 2018 at 5:23 PM Stephan Hoyer <<a href="mailto:shoyer@gmail.com">shoyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Jun 2, 2018 at 12:06 PM Robert Kern <<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We propose first freezing ``RandomState`` as it is and developing a new RNG<br></div><div>subsystem alongside it.  This allows anyone who has been relying on our old</div><div>stream-compatibility guarantee to have plenty of time to migrate.</div><div>``RandomState`` will be considered deprecated, but with a long deprecation</div><div>cycle, at least a few years.  Deprecation warnings will start silent but become</div><div>increasingly noisy over time.  Bugs in the current state of the code will *not*</div><div>be fixed if fixing them would impact the stream.  However, if changes in the</div><div>rest of ``numpy`` would break something in the ``RandomState`` code, we will</div><div>fix ``RandomState`` to continue working (for example, some change in the</div><div>C API).  No new features will be added to ``RandomState``.  Users should</div><div>migrate to the new subsystem as they are able to.<br></div></div></blockquote><div><br></div><div>Robert, thanks for this proposal. I think it makes a lot of sense and will help maintain the long-term viability of numpy.random.</div><div><br></div><div>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?</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>Well, *I* propose `AttributeError`, myself…</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> I suppose this will be your next NEP :).</div></div></div></blockquote></div><div><br></div><div>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.</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Robert Kern</div></div>