[ 
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694646#comment-16694646
 ] 

Gilles commented on RNG-57:
---------------------------

{quote}I think that this may mislead a browser of the user guide that some of 
the RNGs are worse
{quote}
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: https://issues.apache.org/jira/browse/RNG-57
>             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
(v7.6.3#76005)

Reply via email to