[Numpy-discussion] Prototype CorePRNG implementation feedback

[Neal Becker]

What is the syntax to construct an initialized generator?
RandomGenerator(Xoroshiro128(my_seed))?

On Thu, Feb 22, 2018 at 6:06 AM Kevin Sheppard <kevin.k.sheppard at gmail.com>
wrote:

> I have implemented a working prototype of a pluggable RandomState.  The
> repo is located at https://github.com/bashtage/core-prng.
>
> The main design has a small PRNG (currently only SplitMix64 and
> Xoroshiro128 are implemented) that does not have any public functions
> available to generate random numbers.  These objects only expose methods to
> get and set state and to jump the PRNG.
>
> The random number generator is exposed via an opaque structure wrapped in
> a PyCapsule.  This structure has two void pointers, one to the state and
> one to the function that generates the next uint 64.  I think in the
> long-run it might make sense to expose a few additional interfaces, such as
> the next random double (makes sense for dSFMT) or the next random uint32
> (makes sense for MT19937).  For now, I have deliberately kept it simple.
>
> The user-facing object is called `RandomGenerator` and it can be
> initialized using the syntax `RandomGenerator` or
> `RandomGenerator(Xoroshiro128())`.  The object exposes user-facing methods
> (currently only `random_integer` and `random_double`).
>
> A basic demo:
>
> from core_prng.generator import RandomGenerator
> # Splitmix 64 for now
> RandomGenerator().random_integer()
>
> from core_prng.xoroshiro128 import Xoroshiro128
> RandomGenerator(Xoroshiro128()).random_integer()
>
> A few questions that have come up:
>
>    1. Should a passed core PRNG be initialized or not. The syntax RandomGenerator(Xoroshiro128)
>    looks nicer than RandomGenerator(Xoroshiro128())
>    2. Which low-level methods should be part of the core PRNG?  These
>    would all be scalar generators that would be consumed by RandomGenerator
>    and exposed through void *. I could imagine some subset of the
>    following:
>       - uint64
>       - uint32
>       - double
>       - float
>       - uint53 (applicable to PRNGs that use doubles as default type)
>    3. Since RandomState is taken, a new name is needed for the
>    user-facing object.  RandomGenerator is a placeholder but ideally,
>    something meaningful could be chosen.
>    4. I can't see how locking can be usefully implemented in the core
>    PRNGs without a large penalty. This means that these are not threadsafe.
>    This isn't a massive problem but they do access the state (get or set)
>    although with GIL.
>    5. Should state be a property -- this isn't Java...
>
>
> Other feedback is of course also welcome.
>
> Kevin
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180222/a51af2fd/attachment.html>