class SplittableRandom

[Guy Steele]

Maybe "SplittableRandom" should be an interface, and the current implementation called, say, "SplittableRandom64" (for its 64-bit seed).

--Guy

On Jul 16, 2013, at 12:55 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> 
> On Jul 15 2013, at 16:11 , Doug Lea wrote:
> 
>> On 07/15/13 12:59, Martin Buchholz wrote:
>>> If we make the wraparound point for seeds Long.MIN_VALUE instead of 0L, then we
>>> can optimize addGammaModGeorge.
>> 
>> This was a great suggestion; thanks!
>> 
>>> 
>>> I continue to worry that we are producing a PRNG that will end up not being
>>> acceptable to the Monte Carlo simulation community.
>>> 
>> 
>> I'm not sure there is enough of an identifiable community there
>> to decode this. Some people think they need Mersenne Twister,
>> with 4096bit state and 2^4096 periodicity. But that would make
>> a poor candidate for JDK.
> 
> I worry that it will be difficult/impractical for those who desire a different algorithm to replace SplittableRandom with their own (P)RNG whether it be for secure randomness or better statistical properties. Since SplittableRandom doesn't implement any interfaces it's hard to provide any form of substitute except by crufty override of every method. 
> 
> I know that this ground has already been travelled but it remains a concern for me. If only Stream bearing methods were offered there would be little concern but the current implementation will almost certainly be identified by type in fields and method signatures and thus difficult to supplant/work around.
> 
> Useful concrete types without interfaces always make me nervous. :-)
> 
> Mike
> 
>> On the other side, there are people
>> who most care about cost and are happy with a generator that
>> is at least not obviously too regular, but we don't supply those
>> either. The 90+% in between are likely to be happy that JDK8
>> provides something both cheaper and better than java.util.Random
>> to use when it applies.
>> 
>> -Doug
>> 
>