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.dui...@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 >> >
