On Fri, Apr 19, 2019 at 4:54 AM Kevin Sheppard
wrote:
> > Finally, why do we expose the np.random.gen object? I thought part of the
> idea with the new API was to avoid global mutable state.
>
> Module level functions are essential for quick experiments and should be
> provided. The only differe
On Fri, Apr 19, 2019 at 5:16 AM Neal Becker wrote:
> The boost_random c++ library uses the terms 'generators' and
> 'distributions'. Distributions are applied to generators.
>
"distributions" is a little confusing in the context of
scipy.stats.distributions, which a distribution corresponds to
The boost_random c++ library uses the terms 'generators' and
'distributions'. Distributions are applied to generators.
On Fri, Apr 19, 2019 at 7:54 AM Kevin Sheppard
wrote:
>
> > Rather than "base RNG", what about calling these classes a "random source"
> or "random stream"? In particular, I wo
> Rather than "base RNG", what about calling these classes a "random
source"
or "random stream"? In particular, I would suggest defining two Python
classes:
> - np.random.Generator as a less redundant name for what is currently
called
RandomGenerator
> - np.random.Source or np.random.Stream as an
Matti, Kevin and Robert -- thanks for putting this together! I am very
excited about these long awaited improvements to numpy.random.
I have a number of concerns about the user facing API, starting with the
names "Random Generator" and "Base Random Number Generator," which I
suspect will be a sour
Thanks to the work of Kevin Sheppard, Robert Kern and others, the branch
to merge randomgen https://github.com/bashtage/randomgen into numpy is
ready for final review.
The branch is here https://github.com/numpy/numpy/pull/13163. It is
fully backward compatible: numpy.random.mtrand,
numpy.ran
