[Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

[Ralf Gommers]

On Sun, May 24, 2015 at 11:30 AM, Nathaniel Smith <njs at 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.gommers at gmail.com> wrote:
> >
> > On Sun, May 24, 2015 at 10:22 AM, Antony Lee <antony.lee at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150524/25269cd8/attachment.html>