Hello, On Sat, Jan 27, 2018 at 09:28:54AM +0900, Robert Kern wrote:
On Sat, Jan 27, 2018 at 1:14 AM, Kevin Sheppard
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 http://threefry.readthedocs.io/using_from_cython.html 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 numpy.random? Regards, Pierre