On Sat, Jun 16, 2018 at 11:02 AM Ralf Gommers <ralf.gomm...@gmail.com> wrote:
> > > On Sat, Jun 16, 2018 at 12:38 AM, Robert Kern <robert.k...@gmail.com> > wrote: > >> I have incorporated the feedback from this thread, and have significantly >> altered the proposal. I think this version will be more palatable to >> everyone. >> >> https://github.com/numpy/numpy/pull/11356 >> >> https://github.com/rkern/numpy/blob/nep/rng-clarification/doc/neps/nep-0019-rng-policy.rst >> >> I'm pretty sure that Kevin Sheppard's prototype already implements the >> broad strokes of my proposal (seriously, he thinks of everything; I'm just >> playing catch up), so I don't think there is any technical risk. I think >> it's just a matter of the fine details of shoving this into numpy.random >> per se rather than a third party package. >> >> https://bashtage.github.io/randomgen/devel/legacy.html >> >> --- >> >> ============================== >> Random Number Generator Policy >> ============================== >> >> :Author: Robert Kern <robert.k...@gmail.com> >> :Status: Draft >> :Type: Standards Track >> :Created: 2018-05-24 >> > > Thanks Robert. The whole proposal looks good to me now, just one minor > comment below. > > >> >> The initial release of the new PRNG subsystem MUST leave these convenience >> functions as aliases to the methods on a global ``RandomState`` that is >> initialized with a Mersenne Twister basic RNG object. A call to >> ``numpy.random.seed()`` will be forwarded to that basic RNG object. In >> order >> to allow certain workarounds, it MUST be possible to replace the basic RNG >> underneath the global ``RandomState`` with any other basic RNG object (we >> leave >> the precise API details up to the new subsystem). Calling >> ``numpy.random.seed()`` >> thereafter SHOULD just pass the given seed to the current basic RNG >> object and >> not attempt to reset the basic RNG to the Mersenne Twister. The global >> ``RandomState`` instance MUST be accessible by the name >> ``numpy.random.mtrand._rand``: Robert Kern long ago promised >> ``scikit-learn`` >> that this name would be stable. Whoops. >> > > This is a little weird; "mtrand" is an implementation detail already. > There's exactly 3 instances of that in scikit-learn, so replacing those > with a sane name (with a long timeline, say 4 numpy versions at least plus > a major version number bump) doesn't seem unreasonable. > Everything in this paragraph is explicitly just about the initial release with the new subsystem. A following paragraph says that we should revisit all of these in following releases. -- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
