On Tue, Mar 12, 2013 at 10:38 PM, Neal Becker <[email protected]> wrote: > Nathaniel Smith wrote: > >> On Tue, Mar 12, 2013 at 9:25 PM, Nathaniel Smith <[email protected]> wrote: >>> On Mon, Mar 11, 2013 at 9:46 AM, Robert Kern <[email protected]> wrote: >>>> On Sun, Mar 10, 2013 at 6:12 PM, Siu Kwan Lam <[email protected]> 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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
