[SciPy-Dev] Shim for RandomState/Generator

Robert Kern robert.kern at gmail.com
Tue Mar 17 21:48:13 EDT 2020


On Tue, Mar 17, 2020 at 9:22 PM Andrew Nelson <andyfaff at gmail.com> wrote:

> Hi all,
> default random number generation is heading towards use of
> np.random.Generator, with RandomState being preserved for legacy usage. It
> would be nice to start using Generator's, but in order to do that in scipy
> we would need to be able to write code that worked with RandomState or
> Generator.
> Unfortunately there are a few methods that have changed their name,
> `randint `--> `integers` and `rand/random_sample` --> `random` spring to
> mind
>

FWIW, `random` exists in RandomState, too, so it's just a matter of using
the existing common name for that one. `randint` --> `integers` is the only
sticky one that I can recall.


> I was wondering if we could add a shim to go in `scipy._lib._util` that
> would permit code to be written as if it were using the Generator front end
> (at least most of it), but could be using either RandomState or Generator
> as a backend.
>

Instead of a wrapper object, which is inevitably going to be passed around
and thus introducing a third API for code to be aware of, I would recommend
having a set of functions for the few methods that have changed names. I.e.

def rng_integers(gen, low, high=None, ...):
    if isinstance(gen, Generator):
        return gen.integers(low, high=high, ...)
    else:
        return gen.randint(low, high=high, ...)

Yes, this also constitutes a third API, but it's one that can't "escape".
It only affects functions that call these functions because it doesn't
introduce a new object with its own lifetime to consider. It's also limited
to a couple of functions.

-- 
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20200317/0bd42f65/attachment-0001.html>


More information about the SciPy-Dev mailing list