On Sun, Jun 3, 2018 at 5:23 PM Stephan Hoyer <sho...@gmail.com> wrote:
> On Sat, Jun 2, 2018 at 12:06 PM Robert Kern <robert.k...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
