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.
