[Numpy-discussion] NEP: Random Number Generator Policy

[Ralf Gommers]

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.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180616/21a5994c/attachment.html>