[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640723#comment-16640723
]
Gilles commented on RNG-57:
---------------------------
bq. I am wondering if the ProvidersList should make a better attempt at
creating a full length seed.
As you note, the "scramble" method is supposed to avoid obvious pitfalls like
the seed being mostly zeroes or other periodic set of bits.
If only full length seeds were necessary to make tests that use a few generated
numbers pass, I'd guess that it would indicate an expectation problem (thus
change the test) or a dysfunctional RNG (thus fix the RNG).
My preference would be to have the unit test run with different (random) seeds
at each build. Junit can take care of repeating failing tests (called "flaky")
but IIUC, it would only rerun a {{@test}} whereas in this case, it is the
{{ProvidersList}} instance that must be reloaded. So this would imply moving
the code from a {{static}} block to a regular constructor, and pass it to the
unit test classes in a different way.
Currently, I don't think this refactoring is worth the time and the possible
drawbacks.
bq. I can create a temp branch to try different seeds until it passes on Travis
then formulate an atomic PR.
Agreed; the first thing would be to "empirically" try a few seeds to ensure
that the tests pass much more often than they fail.
If that's the case; the stress tests suites will ensure (if the result are OK)
that the cache did not degrade the quality of the randomness of {{nextInt()}}.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> -----------------------------------------------------------
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
> Affects Versions: 1.2
> Reporter: Alex D Herbert
> Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
