[Numpy-discussion] Moving NumPy's PRNG Forward

Pierre de Buyl pierre.debuyl at chem.kuleuven.be
Mon Jan 29 15:39:15 EST 2018


On Sat, Jan 27, 2018 at 09:28:54AM +0900, Robert Kern wrote:
> On Sat, Jan 27, 2018 at 1:14 AM, Kevin Sheppard
> <kevin.k.sheppard at gmail.com> wrote:
> >
> > In terms of what is needed, I think that the underlying PRNG should
> be swappable.  The will provide a simple mechanism to allow certain
> types of advancement while easily providing backward compat.  In the
> current design this is very hard and requires compiling many nearly
> identical copies of RandomState. In pseudocode something like
> >
> > standard_normal(prng)
> >
> > where prng is a basic class that retains the PRNG state and has a
> small set of core random number generators that belong to the
> underlying PRNG -- probably something like int32, int64, double, and
> possibly int53. I am not advocating explicitly passing the PRNG as an
> argument, but having generators which can take any suitable PRNG would
> add a lot of flexibility in terms of taking advantage of improvements
> in the underlying PRNGs (see, e.g., xoroshiro128/xorshift1024).  The
> "small" core PRNG would have responsibility over state and streams.
> The remainder of the module would transform the underlying PRNG into
> the required distributions.
> (edit: after writing the following verbiage, I realize it can be summed
> up with more respect to your suggestion: yes, we should do this design,
> but we don't need to and shouldn't give up on a class with distribution
> methods.)
> Once the core PRNG C API is in place, I don't think we necessarily need
> to move away from a class structure per se, though it becomes an
> option.

(Sorry for cutting so much, I have a short question)

My typical use case for the C API of NumPy's random features is that I start
coding in pure Python and then switch to Cython. I have at least twice in the
past resorted to include "randomkit.h" and use that directly. My last work
actually implements a Python/Cython interface for rngs, see

The goal is to use exactly the same backend in Python and Cython, with a cimport
and a few cdefs the only changes needed for a first port to Cython.

Is this type of feature in discussion or in project for the future of



More information about the NumPy-Discussion mailing list