[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694594#comment-16694594
]
Alex D Herbert commented on RNG-57:
-----------------------------------
{quote}How do you draw that conclusion?
{quote}
Because the number of failures seen across the {{LongProviders}} went up.
However the change is not dramatic and most could be attributed to different
random seeds. As I pointed out a few of the tests are marginal fails on
BigCrush. I think the change has definitely made TWO_CMRES fail the
dieharder_dna test.
I realised that rerunning the tests for the {{IntProviders}} is not needed
other than to get more results. The implementation tested ({{nextInt}}) has not
changed. So in the interest of completeness I am running the tests 3 more times
for the {{LongProviders}}. That will provide 6 sets of results for DieHarder
and BigCrush for all providers. 6 new sets for the {{LongProviders}} and 3 new
sets to complement the existing 3 sets for {{IntProviders}}.
The results should be finished tomorrow. How do you want to receive the raw
text files? I can put them into the src/site directory in rng-parent. I can
overwrite the old {{LongProvider}} results or add new folders.
{quote}the note indicates that "diehard_sums" may not be trusted (as per the
note on the software's web site), not that it is not counted.
{quote}
I think that this may mislead a browser of the user guide that some of the RNGs
are worse when actually they fail a test that should not be used. Here's what
the software says about it:
{noformat}
> dieharder -d 14 -h
# Comments
#
# At this point I think there is rock solid evidence that this test
# is completely useless in every sense of the word. It is broken,
# and it is so broken that there is no point in trying to fix it.
# The problem is that the transformation above is not linear, and
# doesn't work. Don't use it.
#
# For what it is worth, rgb_lagged_sums with ntuple 0 tests for
# exactly the same thing, but scalably and reliably without the
# complication of overlapping samples and covariance. Use it
# instead.
{noformat}
The fact that it is stated that the test should not be used justifies removing
it from the results table. If it is not removed then a flag to indicate that
WELL_1024_A and WELL_44497_B failed 1 test but it was dieharder_sums would be
useful.
I do not think that many will actually click through and digest the results in
full. If they do then a note that the dieharder_sums test is ignored in the
main table should be known to that type of user.
> 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)
