RFR 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom

[Peter Levart]

On 08/19/2013 01:07 PM, Paul Sandoz wrote:
> Hi,
>
> This patch updates Random and ThreadLocalRandom to have functional consistency (for the most part) across Random, ThreadLocalRandom and SplittableRandom:
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/overview-summary.html
>
>
> The PRNG of ThreadLocalRandom has been updated by Doug:
>
>       * Even though this class subclasses java.util.Random, it uses the
>       * same basic algorithm as java.util.SplittableRandom.  (See its
>       * internal documentation for explanations, which are not repeated
>       * here.)  Because ThreadLocalRandoms are not splittable
>       * though, we use only a single 64bit gamma.
>
>
> The stream-returning method gaussians() is removed from Random and TLR. Doug's explanation as to why SplittableRandom does not have nextGaussian is applicable to why it's not worth having sized and effectively infinite stream-returning gaussians() methods:
>
> "There are many algorithms to choose from, that are all
> independent of the underlying uniform RNG algorithm.
> Plus, there are many more probability distributions
> out there. Singling out a particular algorithm/method
> for Gaussian stands mostly as an accident of history
> in java.util.Random."
>
>
> The nextFloat functionality has been left unmodified. Such un/bounded nextFloat methods do not exist on SplittableRandom, i don't think they carry their weight given the nextDouble functionality.
>
>
> I have yet to define a common interface e.g. RandomGenerator that Random, ThreadLocalRandom and SplittableRandom could implement, but it would be very easy to do so. Any thoughts on doing this?

Hi Paul,

Yes, a common interface is something that I missed sometimes. But now 
that we have lambdas and method references, it's not difficult to just 
adapt someRandom::nextLong to a LongSupplier or someRandom::nextDouble 
to a DoubleSupplier, so it somehow looses the importance. Anyway, a 
special interface might be a better fit for APIs taking random 
generators as parameters from self-documenting perspective. The consumer 
of such interface can also have more methods to choose from - it's not 
just a functional interface. So I'm for such interface.

Regards, Peter

> --
>
> A JPRT run reported no corresponding failures.
>
> Paul.