commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
Date Mon, 08 Oct 2018 12:14:00 GMT

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

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

{quote}Because they are not all perfect.
{quote}
I was expecting the answer.
{quote}The DieHarder results show that.
{quote}
Indeed. And it is unlikely that the unit tests of "Commons RNG" can do better than the "Big
Crush" test suite. Thus I don't think that we should evaluate the quality of the underlying
source: the unit test should identify a bug in the Java implementation, not a flawed RNG algorithm.

If the issue here is not a seed problem, we can make the build more robust by setting the
JUnit config to  repeat "flaky" tests.  If some RNG sources fail more often than others,
it is already a piece of information, while being more tolerant for bad generators is not
a good idea IMO.

> 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)

Mime
View raw message