[Numpy-discussion] Adopt Mersenne Twister 64bit?

Robert Kern robert.kern@gmail....
Tue Mar 12 18:10:04 CDT 2013


On Tue, Mar 12, 2013 at 10:38 PM, Neal Becker <ndbecker2@gmail.com> wrote:
> Nathaniel Smith wrote:
>
>> On Tue, Mar 12, 2013 at 9:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
>>> On Mon, Mar 11, 2013 at 9:46 AM, Robert Kern <robert.kern@gmail.com> wrote:
>>>> On Sun, Mar 10, 2013 at 6:12 PM, Siu Kwan Lam <siu@continuum.io> wrote:
>>>>> My suggestion to overcome (1) and (2) is to allow the user to select
>>>>> between the two implementations (and possibly different algorithms in the
>>>>> future). If user does not provide a choice, we use the MT19937-32 by
>>>>> default.
>>>>>
>>>>>         numpy.random.set_state("MT19937_64", …)   # choose the 64-bit
>>>>> implementation
>>>>
>>>> Most likely, the different PRNGs should be different subclasses of
>>>> RandomState. The module-level convenience API should probably be left
>>>> alone. If you need to control the PRNG that you are using, you really
>>>> need to be passing around a RandomState instance and not relying on
>>>> reseeding the shared global instance.
>>>
>>> +1
>>>
>>>> Aside: I really wish we hadn't
>>>> exposed `set_state()` in the module API. It's an attractive nuisance.
>>>
>>> And our own test suite is a serious offender in this regard, we have
>>> tests that fail if you run the test suite in a non-default order...
>>>   https://github.com/numpy/numpy/issues/347
>>>
>>> I wonder if we dare deprecate it? The whole idea of a global random
>>> state is just a bad one, like every other sort of global shared state.
>>> But it's one that's deeply baked into a lot of scientific programmers
>>> expectations about how APIs work...
>>
>> (To be clear, by 'it' here I meant np.random.set_seed(), not the whole
>> np.random API. Probably. And by 'deprecate' I mean 'whine loudly in
>> some fashion when people use it', not 'rip out in a few releases'. I
>> think.)
>>
>> -n
>
> What do you mean that the idea of global shared state is a bad one?

The words "global shared state" drives fear into the hearts of
experienced programmers everywhere, whatever the context. :-) It's
rarely a *good* idea.

> How would
> you prefer the API to look?

There are two current APIs:

1. Instantiate RandomState and call it's methods
2. Just call the functions in numpy.random

The latter has a shared global state. In fact, all of those
"functions" are just references to the methods on a shared global
RandomState instance.

We advocate using the former API. Note that it already exists. It was
the recommended API from day one. No one is recommending adding a new
API.

> An alternative is a stateless rng, where you have
> to pass it it's state on each invocation, which it would update and return.  I
> hope you're not advocating that.

No. This is a place where OOP solved the problem neatly.

-- 
Robert Kern


More information about the NumPy-Discussion mailing list