On Mon, Mar 11, 2013 at 9:46 AM, Robert Kern <robert.k...@gmail.com> wrote: > On Sun, Mar 10, 2013 at 6:12 PM, Siu Kwan Lam <s...@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... -n _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion