[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635714#comment-16635714
]
Alex D Herbert commented on RNG-57:
-----------------------------------
{quote}Perhaps add a table for "nextBoolean()"{quote}
Updating the performance benchmark to have nextBoolean is a good idea. When run
it should show that nextInt is faster than nextLong for the {{LongProviders}}
and nextBoolean is faster than nextInt or nextLong respectively.
{quote}That should not be necessary (cf. above).{quote}
I think it is necessary as the nextInt from the long provider only used the
lower 32-bits. It is possible these providers do not have as much randomness in
the upper 32-bits. The only way to know is to rerun the tests.
It is also then serves to document the randomness of nextLong, which was
previously missing from the User Guide.
{quote}Your suggested division looks fine.{quote}
OK. I will add support for caching values for nextBoolean and nextInt to the
abstract providers.
I've committed a few times to my local testing branch. I'll discard all this
and create a new branch with the changes for a PR as {{improvement-RNG-57}}.
_Unless you really want the history of the testing preserved somehow._ The
history basically contains a few different methods that were tested.
{quote}I could have a look at the RestorableUniformRandomProvider part{quote}
I'm fine with that since there are a few ways to do it. I'll leave it to you to
decide what fits the best with the design.
> 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)
