commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
Date Wed, 21 Nov 2018 12:22:00 GMT


Gilles commented on RNG-57:

{quote}I think that this may mislead a browser of the user guide that some of the RNGs are
This would only result from not reading the docs correctly.
 I admit that we can/could put more info but if the premise is that it won't be read thoroughly...

The initial idea (of including the output of external tools) was to show that users should
not blindly use the JDK's {{Random}} class (and that's pretty clear from the userguide).

Going beyond that is fine on the condition that we provide a robust script that will start
"DieHarder" and "[Big]Crush", then parse their outputs and generate the table(s) to be readily
included in the docs. Personally, I don't think it's worth the time: It's the second time
I run them (not counting the "trials and errors" pre-initial release). Will you do it?

By the same token, I'd not add more data to the table; 3 runs is fine to show that results
do vary.
 Again, unless there is a script and you want to run the suites many more times in order to
be able to make histograms...

bq. I think the change has definitely made TWO_CMRES fail the dieharder_dna test.

What can we conclude from that?

> CachedUniformRandomProvider for nextBoolean() and nextInt()
> -----------------------------------------------------------
>                 Key: RNG-57
>                 URL:
>             Project: Commons RNG
>          Issue Type: Improvement
>          Components: core
>            Reporter: Alex D Herbert
>            Priority: Minor
>              Labels: performance
>             Fix For: 1.2
> 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

View raw message