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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
