(original) (raw)



On Sat, Jun 16, 2018 at 12:38 AM, Robert Kern <robert.kern@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.


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.


---

==============================
Random Number Generator Policy
==============================

:Author: Robert Kern <robert.kern@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