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

[Martin Buchholz]

I haven't had the time I would have liked to review recent changes to our
prng's, but I am very happy with the direction of this change (and others).
 Especially the use of a better prng with ThreadLocalRandom.  Adding an
interface for all these classes to implement also seems good.  Thanks!

(and there's always more work to do... full support for a variety of
generators and distributions is a career path)


On Mon, Aug 19, 2013 at 4:07 AM, Paul Sandoz <paul.sandoz at oracle.com> 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?
>
> --
>
> A JPRT run reported no corresponding failures.
>
> Paul.