class SplittableRandom

[Doug Lea]

On 07/11/13 15:50, Jeff Hain wrote:
> Doug Lea wrote:
>  >Q: Why isn't SplittableRandom a subclass of Random?
>  >A: Class Random requires thread-safety in its spec. It would be
>  >nonsensical for SplittableRandom to comply.
>
> Random Javadoc states "Instances of java.util.Random are threadsafe."
> but ThreadLocalRandom extends Random and is not, so why not consider
> that the thread-safety statement only applies to Random.class, and
> not to Random subclasses?

ThreadLocalRandoms are (trivially) threadSafe in that you cannot
share them among threads using any sanctioned usage construction.

>
> What I would have used (maybe because I'm not an expert!) is something
> like this:
>      new Subtask(new MySequentialRandom(currentTaskRandom.nextLong())).fork()


One way to think of SplittableRandom is that it makes your idea
behind this code actually work. As it stands, if you were to do
this with java.util.Random, both would generate the same sequence.

>
> The Javadoc for split() says that the values of the returned object
> should have the same (i.e. as good?) statistical properties, but wouldn't
> it also be the case with a good non-thread-safe Random, like based on
> MersenneTwister, which could be seeded with multiple longs?

It might be. It wasn't until a paper in PPoPP last year that
researchers started looking more systematically at the independence
properties of these parent-child generators. And of those we
know something about, SplittableRandom's algorithm seems to
be simplest and fastest. But if a better one comes along,
we can plug it in; nothing in the specs requires the current
implementation.

>
> With this method:
>      public double nextDouble() {
>          long bits = (1023L << 52) | (nextLong() >>> 12);
>          return Double.longBitsToDouble(bits) - 1.0;
>      }
> the returned value granularity is only 1/2^52,

Thanks. I'll relay this to a floating-point expert
I know :-) and see whether we can/should improve it.

>
> 4) nextGaussian()
>
> Currently there is no nextGaussian():
> if added, would it use Random/TLR's algorithm,
> or some variation of the Ziggurat method
> (which can be about four times faster)?

You've just answered why it is not there, and mostly
answered why it shouldn't be there in any upcoming interface.
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.

-Doug