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. Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
