<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 16, 2018 at 12:38 AM, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have incorporated the feedback from this thread, and have significantly altered the proposal. I think this version will be more palatable to everyone.<div><br></div><div>  <a href="https://github.com/numpy/numpy/pull/11356" target="_blank">https://github.com/numpy/<wbr>numpy/pull/11356</a><br></div><div>  <a href="https://github.com/rkern/numpy/blob/nep/rng-clarification/doc/neps/nep-0019-rng-policy.rst" target="_blank">https://github.com/rkern/<wbr>numpy/blob/nep/rng-<wbr>clarification/doc/neps/nep-<wbr>0019-rng-policy.rst</a></div><div><br></div><div>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.</div><div><br></div><div>  <a href="https://bashtage.github.io/randomgen/devel/legacy.html" target="_blank">https://bashtage.github.io/<wbr>randomgen/devel/legacy.html</a><br></div><div><div><br></div><div>---</div><div><br></div><div><div><div class="h5"><div>==============================</div><div>Random Number Generator Policy</div><div>==============================</div><div><br></div><div>:Author: Robert Kern <<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>></div><div>:Status: Draft</div><div>:Type: Standards Track</div><div>:Created: 2018-05-24</div></div></div></div></div></div></blockquote><div><br></div><div>Thanks Robert. The whole proposal looks good to me now, just one minor comment below.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div class="h5"><br></div></div><div><br></div><div>The initial release of the new PRNG subsystem MUST leave these convenience</div><div>functions as aliases to the methods on a global ``RandomState`` that is</div><div>initialized with a Mersenne Twister basic RNG object.  A call to</div><div>``numpy.random.seed()`` will be forwarded to that basic RNG object.  In order</div><div>to allow certain workarounds, it MUST be possible to replace the basic RNG</div><div>underneath the global ``RandomState`` with any other basic RNG object (we leave</div><div>the precise API details up to the new subsystem).  Calling ``numpy.random.seed()``</div><div>thereafter SHOULD just pass the given seed to the current basic RNG object and</div><div>not attempt to reset the basic RNG to the Mersenne Twister.  The global</div><div>``RandomState`` instance MUST be accessible by the name</div><div>``numpy.random.mtrand._rand``: Robert Kern long ago promised ``scikit-learn``</div><div>that this name would be stable.  Whoops.</div></div></div></div></blockquote><div><br></div><div>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. <br></div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br></div></div></div></div>