[Numpy-discussion] NEP: Random Number Generator Policy (original) (raw)

Robert Kern robert.kern at gmail.com
Sat Jun 16 17:58:47 EDT 2018

On Sat, Jun 16, 2018 at 11:02 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

On Sat, Jun 16, 2018 at 12:38 AM, Robert Kern <robert.kern at 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.kern at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180616/5488dda1/attachment.html>

More information about the NumPy-Discussion mailing list