[Numpy-discussion] Proposal: numpy.random.random_seed

Robert Kern robert.kern at gmail.com
Tue May 17 13:41:31 EDT 2016


On Tue, May 17, 2016 at 6:24 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
> On May 17, 2016 1:50 AM, "Robert Kern" <robert.kern at gmail.com> wrote:
> >
> [...]
> > What you want is a function that returns many RandomState objects that
are hopefully spread around the MT19937 space enough that they are
essentially independent (in the absence of true jumpahead). The better
implementation of such a function would look something like this:
> >
> > def spread_out_prngs(n, root_prng=None):
> >     if root_prng is None:
> >         root_prng = np.random
> >     elif not isinstance(root_prng, np.random.RandomState):
> >         root_prng = np.random.RandomState(root_prng)
> >     sprouted_prngs = []
> >     for i in range(n):
> >         seed_array = root_prng.randint(1<<32, size=624)  #
dtype=np.uint32 under 1.11
> >         sprouted_prngs.append(np.random.RandomState(seed_array))
> >     return spourted_prngs
>
> Maybe a nice way to encapsulate this in the RandomState interface would
be a method RandomState.random_state() that generates and returns a new
child RandomState.

I disagree. This is a workaround in the absence of proper jumpahead or
guaranteed-independent streams. I would not encourage it.

> > Internally, this generates seed arrays of about the size of the MT19937
state so make sure that you can access more of the state space. That will
at least make the chance of collision tiny. And it can be easily rewritten
to take advantage of one of the newer PRNGs that have true independent
streams:
> >
> >   https://github.com/bashtage/ng-numpy-randomstate
>
> ... But unfortunately I'm not sure how to make my interface suggestion
above work on top of one of these RNGs, because for
RandomState.random_state you really want a tree of independent RNGs and the
fancy new PRNGs only provide a single flat namespace :-/. And even more
annoyingly, the tree API is actually a nicer API, because with a flat
namespace you have to know up front about all possible RNGs your code will
use, which is an unfortunate global coupling that makes it difficult to
compose programs out of independent pieces, while the
RandomState.random_state approach composes beautifully. Maybe there's some
clever way to allocate a 64-bit namespace to make it look tree-like? I'm
not sure 64 bits is really enough...

MT19937 doesn't have a "tree" any more than the others. It's the same flat
state space. You are just getting the illusion of a tree by hoping that you
never collide. You ought to think about precisely the same global coupling
issues with MT19937 as you do with guaranteed-independent streams.
Hope-and-prayer isn't really a substitute for properly engineering your
problem. It's just a moral hazard to promote this method to the main API.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160517/a21d4c7f/attachment.html>


More information about the NumPy-Discussion mailing list