On Sun, Jun 3, 2018 at 11:07 PM Kevin Sheppard <kevin.k.shepp...@gmail.com> wrote:
> The seed() discussion seems unnecessary. StableRandom will need to have a > method to set/get state > > which can be used by any project that needs to get reproducible numbers > from the module-level generator. > > > > While this is an implementation detail, many generators have much smaller > states than MT19937 > > (a few uint64s). So this is easy enough to hard code where needed. > The question isn't about what .seed() methods look like on the new generators. Rather, it's about the behavior when code calls numpy.random.seed() then numpy.random.uniform() (or one of the other convenience aliases). Specifically, there will be a period of time when RandomState is merely deprecated but is still expected to be there and be fully backwards-compatible to give reproducible streams. Does that expectation extend to code that uses numpy.random.seed() to get that reproducibility? What happens with code that just calls numpy.random.uniform(): does it use RandomState or the new code? These questions are probably in-scope for this NEP, but I'd like to get some kind of consensus on the rest first, as the higher level decisions will tell us more about what we want to do for numpy.random.seed(). -- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
