[Numpy-discussion] NEP: Random Number Generator Policy

[Robert Kern]

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>