SplittableGenerator of JEP 356

[Michael Bien]

Thank you for the explanation,

This makes sense - I only wanted to bring it up in the (unlikely) case 
it was an oversight.

My thinking was that there might be a potential use case of something like:

     private static final SecureRandom shared_source = new 
SecureRandom(); // thread safe source
     private static final SplittableGenerator shared_splitter
             = 
RandomGeneratorFactory.<SplittableGenerator>of("L32X64MixRandom").create();

     private final RandomGenerator local_random = 
shared_splitter.split(shared_source);  // not secure but local

Which would exploit the fact that secure random is thread safe and a 
pretty good source from my understanding. This could be used when the 
contention on the source is not a big concern.

A much better (and contention free) way is to split before forking a 
task with only SplittableGenerators involved, which is probably another 
good reason to not encourage the code above by enforcing 
SplittableGenerators in the API.

best regards,
michael


On 13.07.21 18:58, Jim Laskey wrote:
>  From Guy:
>
> 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.)
>
> —Guy Steele
>
>
>> 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.
>>
>> -michael
>>
>> On 13.07.21 14:45, Michael Bien wrote:
>>> Hello,
>>>
>>> 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,
>>>
>>> michael
>>>