RFR 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom
martinrb at google.com
Mon Aug 19 21:28:35 UTC 2013
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:
> This patch updates Random and ThreadLocalRandom to have functional
> consistency (for the most part) across Random, ThreadLocalRandom and
> 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.
More information about the core-libs-dev