New candidate JEP: 356: Enhanced Pseudo-Random Number Generators

[Guy Steele]

> On Jun 24, 2019, at 3:46 AM, Kasper Nielsen <kasperni at gmail.com> wrote:
> 
> Hi Guy,
> 
> This looks really good, a couple of quick questions and comments.
> 
> 1)
> I think a natural home for this would be java.math?

Good suggestion; but others have suggested making a new package java.util.random.
One advantage of this is that it would provide a natural home for documentation
providing an overview of the entire Rng API design, including advice on how to pick
a PRNG algorithm suitable for your application.

> 2)
> Couldn't we use default methods and skip all of the abstract classes?
> I assume all the abstract classes are stateless. Don't know if there
> would be performance penalties though.

Turns out that some of the default methods need a lot of non-public helper methods
and inner classes.  Abstracts classes were a convenient way to organize them.

Only two of the abstract classes are public, and only implementors of new PRNG
algorithms need to know about them.

> 3)
> Wouldn't people have to implement nextBytes() as well.
> An efficient implementation needs to know whether or not the source
> is 32 bit or 64 bit (or maybe 128 bit at some point).
> Which is difficult if we only have a single base class.
> Maybe create Rng32, Rng64 that extends from Rng

Our current take on it is that the intended applications for this API are
rather different from those that use SecureRandom.  If we’re wrong,
we can easily add nextBytes() later.  (And some would argue that we should
also have nextInts() and nextLongs() and maybe nextFloats() and nextDoubles().
I think we should wait for some user feedback before going there.)

> 4)
> Can we add an interface for generating seeds?
> 
> public interface SeedGenerator {
>  default generateLong() {
>    return Long.convert(generateSeed(8));
>  }
>  byte[] generateSeed(int length);
> }
> 
> Right now we have a mix of long and byte[]. And if you have
> algorithms that need 128 bit seeds and you store all your states
> in longs. Having something like this would be really useful.

I agree that this may be worth more attention.

> 5)
> A clone() or copy() method would also be nice. It is really useful for testing.

Implementations of JumpableRng already have a copy() method;
it wouldn’t be hard to extend this to StreamableRng.  I am a little worried
about extending it to Rng, because implementations of Rng might represent
truly random generators that use physical source, and we would need to decide
what it means to “copy” such a source.

> 6)
> Is reseeding going to be part of the API? I've never really liked having to
> use Random.setSeed() but understand it can be useful, for example, for
> algorithms that are secure.

For now, no.  We see no perceived need.  The instances are fairly lightweight;
it’s just as easy to make a new one as to reseed an old one.

> 7)
> It would be really if we got a simple utility class that allows sampling from
> common non-uniform distributions:
> 
> public static IntSupplier poissonSamplingGenerator(Rng r, double mean)
> public static IntStream poissonSamplingStream(Rng r, double mean)

A great idea, but outside the scope of this JEP.

> Thanks
>  Kasper