On Sun, May 24, 2015 at 11:30 AM, Nathaniel Smith <n...@pobox.com> wrote:
> So with this proposal, an unseeded RandomState uses the latest version -> > therefore the global functions, which start out unseeded, start out using > the latest version. If you call .seed() on an existing RandomState object > and pass in a seed but no version= argument, the version gets reset to 0 -> > therefore if you call the global seed() function and pass in a seed but no > version= argument, the global RandomState gets reset to version 0 (at least > until the next time seed() is called), and backcompat is preserved. > > On May 24, 2015 2:03 AM, "Ralf Gommers" <ralf.gomm...@gmail.com> wrote: > > > > On Sun, May 24, 2015 at 10:22 AM, Antony Lee <antony....@berkeley.edu> > wrote: > >> > >> Hi, > >> > >> As mentioned in > >> > >> #1450: Patch with Ziggurat method for Normal distribution > >> #5158: ENH: More efficient algorithm for unweighted random choice > without replacement > >> #5299: using `random.choice` to sample integers in a large range > >> #5851: Bug in np.random.dirichlet for small alpha parameters > >> > >> some methods on np.random.RandomState are implemented either > non-optimally (#1450, #5158, #5299) or have outright bugs (#5851), but > cannot be easily changed due to backwards compatibility concerns. While > some have suggested new methods deprecating the old ones (see e.g. #5872), > some consensus has formed around the following ideas (see #5299 for > original discussion, followed by private discussions with @njsmith): > >> > >> - Backwards compatibility should only be provided to those who were > explicitly instantiating a seeded RandomState object or reseeding a > RandomState object to a given value, and drawing variates from it: using > the global methods (or a None-seeded RandomState) was already > non-reproducible anyways as e.g. other libraries could be drawing variates > from the global RandomState (of which the free functions in np.random are > actually methods). Thus, the global RandomState object should use the > latest implementation of the methods. > > > > > > The rest of the proposal looks good to me, but the reasoning on this > point is shaky. np.random.seed() is *very* widely used, and works fine for > a test suite where each test that needs random numbers calls seed(...) and > is run with nose. Can you explain why you need to touch the behavior of the > global methods in order to make RandomState(version=) work? > You're absolutely right about it being important to preserve the behavior > of the global functions when seeded, but I think this is just a bug in the > description of the proposal here, not in the proposal itself :-). If you > look at the PR, there's no change to how the global functions work -- > they're still just a transparently thin wrapper around a hidden, global > RandomState object, and thus IIUC changes to RandomState will automatically > apply to the global functions as well. > > Thanks for the clarification. Then +1 from me for this proposal. Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
