<div dir="ltr">On Sun, Jun 10, 2018 at 7:46 PM <<a href="mailto:josef.pktd@gmail.com">josef.pktd@gmail.com</a>> wrote:<br>><br>> On Sun, Jun 10, 2018 at 9:08 PM, Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>> wrote:<br>>><br>>> On Sun, Jun 10, 2018 at 5:27 PM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br>>> ><br>>> > On Mon, Jun 4, 2018 at 3:18 PM, Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>> wrote:<br>>> >><br>>> >> On Sun, Jun 3, 2018 at 8:22 PM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br>>> >>><br>>> >>> It may be worth having a look at test suites for scipy, statsmodels, scikit-learn, etc. and estimate how much work this NEP causes those projects. If the devs of those packages are forced to do large scale migrations from RandomState to StableState, then why not instead keep RandomState and just add a new API next to it?<br>>> >><br>>> >> The problem is that we can't really have an ecosystem with two different general purpose systems.<br>>> ><br>>> > Can't = prefer not to.<br>>><br>>> I meant what I wrote. :-)<br>>><br>>> > But yes, that's true. That's not what I was saying though. We want one generic one, and one meant for unit testing only. You can achieve that in two ways:<br>>> > 1. Change the current np.random API to new generic, and add a new RandomStable for unit tests.<br>>> > 2. Add a new generic API, and document the current np.random API as being meant for unit tests only, for other usage <new API> should be preferred.<br>>> ><br>>> > (2) has a couple of pros:<br>>> > - you're not forcing almost every library and end user out there to migrate their unit tests.<br>>><br>>> But it has the cons that I talked about. RandomState *is* a fully functional general purpose PRNG system. After all, that's its current use. Documenting it as intended to be something else will not change that fact. Documentation alone provides no real impetus to move to the new system outside of the unit tests. And the community does need to move together to the new system in their library code, or else we won't be able to combine libraries together; these PRNG objects need to thread all the way through between code from different authors if we are to write programs with a controlled seed. The failure mode when people don't pay attention to the documentation is that I can no longer write programs that compose these libraries together. That's why I wrote "can't". It's not a mere preference for not having two systems to maintain. It has binary Go/No Go implications for building reproducible programs.<br>><br>> I don't understand this part.<br>> For example, scipy.stats and scikit-learn allow the user to provide a RandomState instance to the functions. I don't see why you want to force down stream libraries to change this. A random state argument should be (essentially) compatible with whatever the user uses, and there is no reason to force packages to update there internal use like in unit tests if they don't want to, e.g. because of the instability.<br>><br>> Aside to statsmodels: We currently have very few user facing random functions, those are just in maybe 3 to 5 places where we have simulated or bootstrap values.<br>> Most of the other uses of np.random are in unit tests and some in the documentation examples.<br><br>Please consider my alternative proposal. Your feedback has convinced me that that's a better approach than the StableRandom as laid out in the NEP. I'm even willing to not deprecate the name RandomState.<br><br>--<br>Robert Kern</div>