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