SplittableGenerator of JEP 356
james.laskey at oracle.com
Tue Jul 13 16:58:59 UTC 2021
You are right that the comment in the JEP was a little loose, and that the implementation(s) of the split/splits methods could in principle draw random values from a RandomGenerator that is not itself splittable. There might even be applications for such functionality.
However, we chose not to support that more general functionality for a fairly subtle reason: there are concerns that if a PNRG is less than perfect, using it as a source of entropy for seeding a PRNG that uses a different algorithm might result in unexpected correlations that could drastically reduce the quality of the output of the new PRNG instance. Restricting the implementation of the split method so that it always constructs a new generator of the same class has allowed us the opportunity to test each class separately and independently for quality of output when the split method is used.
Programmers who know what they are doing can get the effect of the more general split functionality by calling constructors explicitly. This forces them to think about the specific algorithms. For example:
RandomGenerator r = new SplittableRandom();
RandomGenerator g = new L64X256MixRandom(r.nextLong(), r.nextLong(),
r.nextLong(), r.nextLong(), r.nextLong(), r.nextLong());
The programmer may then reason that, in this specific case, the fact that the period of r is only 2^64 implies that the last four values generated cannot all be zero, which is one desideratum for g to have good quality. (The programmer would also have the responsibility to decide more generally whether this particular combination of entropy source and generated instance will in fact have good quality.)
> On Jul 13, 2021, at 11:52 AM, Michael Bien <mbien42 at gmail.com> wrote:
> just wanted to add that the JEP says: "SplittableRandomGenerator extends RandomGenerator and also provides
> methods named split and splits. Splittability allows the user to spawn a new RandomGenerator from an existing RandomGenerator that will generally produce statistically independent results."
> which adds to my suspicion that this might be a api bug.
> On 13.07.21 14:45, Michael Bien wrote:
>> i was wondering if SplittableGenerator.split(SplittableGenerator source) is missing out on a potential usecase when the source itself is not splittable. The implementation looks like it only requires basic calls which could be also provided by the RandomGenerator interface as source.
>> best regards,
More information about the core-libs-dev