[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627234#comment-16627234 ] Alex D Herbert commented on RNG-57: --- Tried a first attempt at this. It is proving quite a challenge to speed it up. Here are the results from 5 runs in JMH generating 10 samples with a standard RNG or one wrapped with a cache. I've implemented methods to speed up {{nextBoolean}} for all providers and {{nextInt}} for {{LongProvider}}. ||Method||randomSourceName||cache||Score||Error||Relative|| |nextBooleanIntProvider|ISAAC|false|5600.46|435.03|1.000| |nextBooleanIntProvider|ISAAC|true|3084.45|26.1|0.551| |nextBooleanIntProvider|JDK|false|9734.99|31.55|1.000| |nextBooleanIntProvider|JDK|true|2947.59|9|0.303| |nextBooleanIntProvider|KISS|false|4799.21|240.71|1.000| |nextBooleanIntProvider|KISS|true|3116.05|12.98|0.649| |nextBooleanIntProvider|MT|false|5658.68|106.18|1.000| |nextBooleanIntProvider|MT|true|3463.81|1212.98|0.612| |nextBooleanIntProvider|MWC_256|false|4101.07|1579.94|1.000| |nextBooleanIntProvider|MWC_256|true|3397.07|1627.95|0.828| |nextBooleanIntProvider|WELL_1024_A|false|7418.54|3146.43|1.000| |nextBooleanIntProvider|WELL_1024_A|true|3042.62|41.56|0.410| |nextBooleanIntProvider|WELL_19937_A|false|8808.53|37.47|1.000| |nextBooleanIntProvider|WELL_19937_A|true|3405.19|28.51|0.387| |nextBooleanIntProvider|WELL_19937_C|false|9740.32|112.33|1.000| |nextBooleanIntProvider|WELL_19937_C|true|2916.81|39.01|0.299| |nextBooleanIntProvider|WELL_44497_A|false|9469.1|110.86|1.000| |nextBooleanIntProvider|WELL_44497_A|true|2914.71|52.34|0.308| |nextBooleanIntProvider|WELL_44497_B|false|9990.53|195.99|1.000| |nextBooleanIntProvider|WELL_44497_B|true|2933.06|36.3|0.294| |nextBooleanIntProvider|WELL_512_A|false|6431.45|173.8|1.000| |nextBooleanIntProvider|WELL_512_A|true|3031.66|25.31|0.471| |nextBooleanLongProvider|MT_64|false|7090.79|3296.42|1.000| |nextBooleanLongProvider|MT_64|true|3029.21|19.46|0.427| |nextBooleanLongProvider|SPLIT_MIX_64|false|3683.5|76.21|1.000| |nextBooleanLongProvider|SPLIT_MIX_64|true|3086.58|105.96|0.838| |nextBooleanLongProvider|TWO_CMRES|false|4802.98|76.5|1.000| |nextBooleanLongProvider|TWO_CMRES|true|3078.19|11.66|0.641| |nextBooleanLongProvider|XOR_SHIFT_1024_S|false|4618.21|12.35|1.000| |nextBooleanLongProvider|XOR_SHIFT_1024_S|true|3068.69|1091.08|0.664| |nextIntLongProvider|MT_64|false|6113.54|10.27|1.000| |nextIntLongProvider|MT_64|true|4695.68|137.97|0.768| |nextIntLongProvider|SPLIT_MIX_64|false|3513.22|34.72|1.000| |nextIntLongProvider|SPLIT_MIX_64|true|3478.33|21.76|0.990| |nextIntLongProvider|TWO_CMRES|false|4569.36|77.06|1.000| |nextIntLongProvider|TWO_CMRES|true|4078.62|218.7|0.893| |nextIntLongProvider|XOR_SHIFT_1024_S|false|4391.85|11.77|1.000| |nextIntLongProvider|XOR_SHIFT_1024_S|true|3843.81|77.38|0.875| The slow generators can be improved. The fast ones are more difficult. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627255#comment-16627255 ] Alex D Herbert commented on RNG-57: --- For reference this is what I tried: {code:java} /** * Wrap an IntProvider instance to enable fast provision of * {@link UniformRandomProvider#nextBoolean()}. */ final static class CachedIntProvider extends IntProvider implements CachedUniformRandomProvider { /** The underlying source of randomness. */ protected final UniformRandomProvider rng; /** * The cached value from a call to random UniformRandomProvider#nextInt(). * * Provides a bit source for booleans. */ private int booleanSource; // Initialised as 0 /** * The bit mask of the boolean source to obtain the boolean bit. * * The bit mask contains a single bit set. * This begins at the least significant bit and is gradually shifted * upwards until overflow to zero. */ private int booleanBitMask; // Initialised as 0 /** * Create a new instance. * * @param rng the source of randomness */ CachedIntProvider(IntProvider rng) { this.rng = rng; } @Override public int next() { // Delegate this return rng.nextInt(); } @Override public boolean nextBoolean() { if (booleanBitMask == 0) { // Get the next value booleanSource = next(); booleanBitMask = 1; } final boolean next = (booleanSource & booleanBitMask) == 0; // Shift up. This will eventually overflow and become zero. booleanBitMask <<= 1; return next; } } {code} > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627283#comment-16627283 ] Gilles commented on RNG-57: --- Nice results! Concerning the design partially shown, I don't understand the purpose of a {{CachedUniformRandomProvider}} interface; the cache is an _implementation_ detail. Either the we provide a high-level "adapter" (through a factory method): {code} final UniformRandomProvider rng = RandomSource.cachingBoolean(UniformRandomProvider delegate) { // Code which you proposed in the above comment: caching // for "nextBoolean()" and delegating the other methods. } {code} or we assume that caching will always be as fast or faster than discarding data, and we implement it in the "core" module. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627396#comment-16627396 ] Alex D Herbert commented on RNG-57: --- {quote}I don't understand the purpose of a CachedUniformRandomProvider interface {quote} It was a class private marker interface. ;) I showed the method in case you could spot something silly. I am going to think about it and try some variants. Anyway the private classes implemented the marker interface to avoid double wrapping. Here is the public API: {code:java} /** * Factory class for wrapping instances of {@link UniformRandomProvider} to cache * values that can be reused to provision the interface methods. * * The int values generated by an {@link IntProvider} can be cached to enable * fast provision of {@link UniformRandomProvider#nextBoolean()}. * The long values generated by a {@link LongProvider} can be cached to enable * fast provision of {@link UniformRandomProvider#nextBoolean()} and * {@link UniformRandomProvider#nextInt()}. */ public final class CachedUniformRandomProviderFactory { // PRIVATE STUFF /** * Wrap the source of randomness. * * The returned provider will cache values from an {@link IntProvider} or * {@link LongProvider} to enable fast provision of * {@link UniformRandomProvider#nextBoolean()}, * and in the case of a {@link LongProvider} also * {@link UniformRandomProvider#nextInt()}. * * If the source of randomness cannot be wrapped then it is returned unmodified. * * @param rng the source of randomness * @return the wrapped uniform random provider */ public static UniformRandomProvider wrap(UniformRandomProvider rng) { // Avoid double wrapping if (rng instanceof CachedUniformRandomProvider) { return rng; } if (rng instanceof LongProvider) { return new CachedLongProvider((LongProvider)rng); } if (rng instanceof IntProvider) { return new CachedIntProvider((IntProvider)rng); } // Unknown implementation return rng; } } {code} Anyway the API details can be sorted. My aim was to see if I could make it work. Currently the {{LongProvider}} uses bit masking on longs. However the results appear to show the {{nextInt}} is faster or equal for all {{LongProviders}}. So I'm going to test a version that uses {{int}} bit masking for the {{nextBoolean}}, having generated an {{int}} using a cached {{long}}. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16630299#comment-16630299 ] Alex D Herbert commented on RNG-57: --- {quote}So I'm going to test a version that uses int bit masking for the nextBoolean, having generated an int using a cached long. {quote} I've done this. It is not faster. The boolean is found using bit shift operations. On a modern machine 64 bit operations are natively supported in the register and as fast as 32 bit operations (AFAIK). So the source should always use the native primitive type of the underlying RNG. As for {{nextBoolean()}} I have tried a few methods and all fast bit shifting variants seem quite similar. Some other methods are definitely worse. I do not want to micro-benchmark this so am fine with this implementation: {code:java} /** * Wrap a LongProvider instance to enable fast provision of * {@link UniformRandomProvider#nextBoolean()}. */ static final class CachedLongProvider extends LongProvider implements CachedUniformRandomProvider { /** The underlying source of randomness. */ private final UniformRandomProvider rng; /** * Provides a bit source for booleans. * * A cached value from a call to random * {@link UniformRandomProvider#nextLong()}. */ private long booleanSource; // Initialised as 0 /** * The bit mask of the boolean source to obtain the boolean bit. * * The bit mask contains a single bit set. * This begins at the least significant bit and is gradually shifted * upwards until overflow to zero. * * When zero a new boolean source should be created and the mask * set to the least significant bit (i.e. 1). */ private long booleanBitMask; // Initialised as 0 /** * Provides a source for ints. * * A cached value from a call to random * {@link UniformRandomProvider#nextLong()}. */ private long intSource; /** Flag to indicate an int source has been cached. */ private boolean cachedIntSource; // Initialised as false /** * Create a new instance. * * @param rng the source of randomness */ CachedLongProvider(LongProvider rng) { this.rng = rng; } @Override public long next() { // Delegate this return rng.nextLong(); } @Override public boolean nextBoolean() { // Shift up. This will eventually overflow and become zero. booleanBitMask <<= 1; // The mask will either contain a single bit or none. if (booleanBitMask == 0) { // Get the next value booleanSource = rng.nextLong(); // Set the least significant bit booleanBitMask = 1; } // Return if the bit is set return (booleanSource & booleanBitMask) != 0; } @Override public int nextInt() { // Directly store and use the long value as a source for ints if (cachedIntSource) { // Consume the cache value cachedIntSource = false; // Return the lower 32 bits return (int) intSource; } // Fill the cache cachedIntSource = true; intSource = rng.nextLong(); // Return the upper 32 bits return (int) (intSource >>> Integer.SIZE); } } {code} The same applies for {{IntProvider}} but just using an {{int}} as the boolean source. I'll run a new benchmark later on a free machine. For this test where the speed differences can be small it helps to have a lot of repeats. I'm also finding that the standard deviation can be quite high. I noticed because some benchmarks use the same method and the standard deviation varies. This could be due to the use of a underlying randomly seeded UniformRandomProvider which may have different run time depending on the sequence. So I am also testing with this which should run in linear time: {code:java} /** * Simple test class to flip the bits in a long and return it. * * Flipping the bits ensures that repeat sampling booleans should be 50:50 * true:false. */ private static final class LongFlip extends LongProvider { /** The value. This is flipped on each call to next(). */ private long value; LongFlip(long seed) { value = seed; } @Override public long next() { // Flip the bits. value = ~value; return value; } } {code} It serves as an optimistic lower limit on the speed of the default implementation of {{nextBoolean()}}. > 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
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631801#comment-16631801 ] Alex D Herbert commented on RNG-57: --- I tried a large benchmark using 100 runs in JMH. The results for {{nextBoolean}} will need more work. They indicate that using bit masking is not as fast as bit shifting for {{IntProvider.}} Bit masking: {code:java} public boolean nextBoolean() { // Shift up. This will eventually overflow and become zero. booleanBitMask <<= 1; // The mask will either contain a single bit or none. if (booleanBitMask == 0) { // Get the next value booleanSource = rng.nextInt(); // Set the least significant bit booleanBitMask = 1; } // Return if the bit is set return (booleanSource & booleanBitMask) != 0; } {code} against bit shifting: {code:java} public boolean nextBoolean() { // Check the current shift. // In multi-thread use the decrement can pass zero // so use <= and not ==. // Note: Current RNG are not thread safe though. if (--discardShift <= 0) { // Set shift to the size of an int discardShift = Integer.SIZE; // Get the next value booleanSource = rng.nextInt(); // Check the most significant bit return (booleanSource >>> 31) != 0; } // The discard shift is in the range 31 to 1 return ((booleanSource << discardShift) >>> 31) != 0; } {code} The difference is significant at the P<0.001 level using a T-Test. Using a {{LongProvider}} and the same ideas the bit masking is faster than the bit shifting. So the different providers demand different methods. This indicates that the 32 bit shifting is relatively faster than bit masking, compared to 64 bit. I'm going to test it on some different machines. For the {{LongProvider}} the {{nextInt}} results are clear: storing a value from {{nextLong}} is optimal: - Method 0 = No cache - Method 1 = Cache the {{long}} from {{nextLong}} - Method 2 = Cache an {{int}} from half of {{nextLong}} ||cacheMethod||randomSourceName||Method||Average||SD||Median||Rel.Average||Rel.Median||T-Test P-value|| |nextIntLongProvider|FLIP|0|2214.4|18.23|2203.48|1.000|1.000|-| |nextIntLongProvider|FLIP|1|2575.88|24.18|2545.56|1.163|1.155|1.36E-16| |nextIntLongProvider|FLIP|2|2737.5|52.86|2657.27|1.236|1.206|-| |nextIntLongProvider|MT_64|0|5909.35|65.69|5775.07|1.000|1.000|-| |nextIntLongProvider|MT_64|1|4431.69|101.07|4257.25|0.750|0.737|0.219| |nextIntLongProvider|MT_64|2|4389.76|45.33|4318.91|0.743|0.748|-| |nextIntLongProvider|SPLIT_MIX_64|0|3568.26|64.09|3488.36|1.000|1.000|-| |nextIntLongProvider|SPLIT_MIX_64|1|3268.32|75.49|3189|0.916|0.914|1.288E-13| |nextIntLongProvider|SPLIT_MIX_64|2|3464.65|27.02|3451.67|0.971|0.989|-| |nextIntLongProvider|TWO_CMRES|0|4496.06|73.06|4446.6|1.000|1.000|-| |nextIntLongProvider|TWO_CMRES|1|3807.1|92.8|3657.3|0.847|0.822|0.905| |nextIntLongProvider|TWO_CMRES|2|3811.41|79.68|3703.69|0.848|0.833|-| |nextIntLongProvider|XOR_SHIFT_1024_S|0|4311.68|3.26|4309.63|1.000|1.000|-| |nextIntLongProvider|XOR_SHIFT_1024_S|1|3559.53|59.25|3479.41|0.826|0.807|1.33E-5| |nextIntLongProvider|XOR_SHIFT_1024_S|2|3724.05|105.79|3543.18|0.864|0.822|-| Note: * The FLIP random source just returns a single value for {{nextLong}} bit flipping it each time. * All results are faster than the native implementation. * For MT_64 method 2 is faster but the T-Test P-value is is not significant (0.22). * For TWO_CMRES the P-value is not significant. * For all other generators method 1 is faster and significant at the P=0.001 level. > 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 >
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633328#comment-16633328 ] Gilles commented on RNG-57: --- About this: {code} static final class CachedLongProvider extends LongProvider implements CachedUniformRandomProvider { {code} I'm not sure whether it is your intended contribution to the codebase or just test code for benchmarking. Unless I'm missing something, I think that the public API should not expose classes with "Cache" in their name. Do your benchmarks show that the cache is always useful for performance (or to never hurt)? If so, it will be always "on" (an implementation detail). If not, or there is some advantage to let the choice to the user (wrap or not), then the public factory methods should be located in {{RandomSource}}, not as a separate factory class. In that case, the API must convey _what_ is provided (faster "nextBoolean()"), not _how_ (caching of "nextInt()" or "nextLong()"). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633915#comment-16633915 ] Alex D Herbert commented on RNG-57: --- {quote}I'm not sure whether it is your intended contribution to the codebase or just test code for benchmarking. Unless I'm missing something, I think that the public API should not expose classes with "Cache" in their name. {quote} This is an internal class. It implements the private interface {{CachedUniformRandomProvider}}. I am currently still investigating things for benchmarking. I now have speed results from 3 machines using Java 8: - MacOS 10.13 : Intel Core i7 2.7GHz (laptop) - Windows 7 : Intel Core i7-2600 3.4 GHz - Linux Ubuntu 16.04 LTS : Intel(R) Xeon(R) CPU E5-1680 v3 @ 3.20GHz The results for the {{nextInt}} for a {{LongProvider}} are all consistent. Caching the long and returning the upper and lower 32 bits is the best method. The results for the {{nextBoolean}} are variable across architectures/platforms. This makes picking one method difficult and I have no idea if the differences are due to chip architecture, the VM on the platform or both. However out of the candidates they are all faster than not doing it. So it may be best to just pick one that works the same way for {{IntProvider}} and {{LongProvider}} (for improved maintainability). Or do a more rigorous investigation of the speed using more architectures and JVMs. {quote}Do your benchmarks show that the cache is always useful for performance (or to never hurt)? If so, it will be always "on" (an implementation detail). {quote} Yes. Adding a cache by default for {{nextInt}} to the {{LongProvider}} would be useful. I think this would be a more commonly used routine, e.g. for array randomisation and to generate {{nextFloat}}. It also has a preferred implementation that is clear from the tests I have done. I see {{nextBoolean}} as more specialised. But it could be added with one of the good implementations. Or the various implementations added to {{commons-rng-examples}}, for instance to {{examples-sampling}}. Adding this functionality as a default would require alterations to support {{RestorableUniformRandomProvider}}. Each provider currently creates and restores its own state as a {{byte[]}} within methods inherited from {{BaseProvider}}: {code:java} protected byte[] getStateInternal(); protected void setStateInternal(byte[] state); {code} The change could alter the inheritance hierarchy so that implementations that inherit from {{LongProvider}} and {{IntProvider}} no longer implement these methods directly. Instead they are implemented at the level of {{Long/IntProvider}} so that the state of the cached {{nextBoolean}} and {{nextInt}} are saved there. The providers can then implement new methods to get the {{byte[]}} representation of their state. This is then combined with the {{byte[]}} representation of the cached values. Note that adding the cache for {{nextInt}} to the {{LongProvider}} would require updating the benchmark tests shown in the [User Guide|https://commons.apache.org/proper/commons-rng/userguide/rng.html] for Performance and Quality. This is not something I have yet investigated so is a big change. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634651#comment-16634651 ] Gilles commented on RNG-57: --- bq. This is an internal class. It implements the private interface {{CachedUniformRandomProvider}}. Internal is good but I think that my remark still hold: an _interface_ is for specifying _what_ not _how_. :) Anyway, this discussion is moot since IIUC the rest of your comment, the performance is always better, and thus the existing classes will just be modified to implement the cache. bq. alterations to support {{RestorableUniformRandomProvider}} Good catch. This should be a separate issue/commit. bq. alter the inheritance hierarchy ? I get that part of the (complete) state should be handled in the base class and part in the concrete subclass. bq. updating the benchmark tests shown in the User Guide The benchmarking code is in class {{GenerationPerformance}} in module {{commons-rng-examples/examples-jmh}}. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634698#comment-16634698 ] Alex D Herbert commented on RNG-57: --- {quote}The benchmarking code is in class GenerationPerformance in module commons-rng-examples/examples-jmh. {quote} I was referring to updating the User Guide by rerunning the benchmark. If the changes go into the existing classes then there should not need to be any changes to the benchmark, just the reporting of the results. The result here show that the system will be faster. But I've not tested if the system then performs worse on the DieHarder or BigCrush tests. {quote}This should be a separate issue/commit. {quote} This is my understanding of the current tasks: * Pick the best method for {{nextBoolean}} (the remaining topic of this issue) * Add a cache for {{nextInt}} to the {{LongProvider}} * Add a cache for {{nextBoolean}} to the {{LongProvider}} * Add a cache for {{nextBoolean}} to the {{IntProvider}} * Update the {{Long/IntProvider}} to save part of the state for {{RestorableUniformRandomProvider}} to a {{byte[]}} * Modify all derived classes to add implementation specific state to the partial state {{byte[]}} * Ensure JUnit tests exist to test save/restore state part way through sampling booleans (and int) from a cached source of random bits * Rerun the performance speed tests for {{LongProvider}} and update the User Guide * Rerun the DieHarder and BigCrush tests for {{LongProvider}} and update the User Guide Q. How should this be divided up into issues and PRs? I've added separations for suggested groupings. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635531#comment-16635531 ] Gilles commented on RNG-57: --- bq. I was referring to updating the User Guide by rerunning the benchmark. So did I. Only the "Generating int values" table must be changed. Correct? Perhaps add a table for "nextBoolean()"? bq. I've not tested if the system then performs worse on the DieHarder or BigCrush tests. These tools test randomness in chunks of 32 bits. IIRC, the Java code that bridges to them only calls the {{nextInt()}} method. So the only impact would a bug in the implementation of the {{nextInt()}} cache on a {{LongProvider}}; but there should be a unit test for that (rather than rely on long-running external software). bq. Rerun the DieHarder and BigCrush tests for LongProvider That should not be necessary (cf. above). Unless you suspect that some of the good results were because half of the generated bits were thrown away... (?) bq. How should this be divided up into issues and PRs? Your suggested division looks fine. I could have a look at the {{RestorableUniformRandomProvider}} part (unless you absolutely want to do it). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636050#comment-16636050 ] Gilles commented on RNG-57: --- {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. {quote} You are right indeed. Given that is the stress test suites are quite time-consuming (especially "Big Crush" of TestU01), I'll rerun them after the "feature-freeze". ;) bq. Unless you really want the history of the testing preserved somehow. I don't think that it is necessary; this JIRA report documents pretty well that your analysis has been fairly thorough and led to the best alternative being committed into the code repository. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636051#comment-16636051 ] Gilles commented on RNG-57: --- {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. {quote} You are right indeed. Given that is the stress test suites are quite time-consuming (especially "Big Crush" of TestU01), I'll rerun them after the "feature-freeze". ;) bq. Unless you really want the history of the testing preserved somehow. I don't think that it is necessary; this JIRA report documents pretty well that your analysis has been fairly thorough and led to the best alternative being committed into the code repository. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636686#comment-16636686 ] Alex D Herbert commented on RNG-57: --- After some more benchmarking I cannot categorically state that one method is preferred over the other for speed. However the method using bit masking (see earlier post) improves performance for both Int and Long providers across all tested platforms. This method is intuitive and should be maintainable in the future. Here are the results for {{nextBoolean}}: ||RNG||Test||Relative|| |ISAAC|Linux|0.552| |ISAAC|Mac|0.493| |ISAAC|Windows|0.519| |JDK|Linux|0.281| |JDK|Mac|0.266| |JDK|Windows|0.283| |KISS|Linux|0.552| |KISS|Mac|0.578| |KISS|Windows|0.493| |MT|Linux|0.476| |MT|Mac|0.476| |MT|Windows|0.380| |MT_64|Linux|0.767| |MT_64|Mac|0.751| |MT_64|Windows|0.767| |MWC_256|Linux|0.698| |MWC_256|Mac|0.689| |MWC_256|Windows|0.700| |SPLIT_MIX_64|Linux|0.872| |SPLIT_MIX_64|Mac|0.909| |SPLIT_MIX_64|Windows|0.872| |TWO_CMRES|Linux|0.854| |TWO_CMRES|Mac|0.825| |TWO_CMRES|Windows|0.854| |WELL_1024_A|Linux|0.387| |WELL_1024_A|Mac|0.412| |WELL_1024_A|Windows|0.363| |WELL_19937_A|Linux|0.317| |WELL_19937_A|Mac|0.350| |WELL_19937_A|Windows|0.311| |WELL_19937_C|Linux|0.300| |WELL_19937_C|Mac|0.330| |WELL_19937_C|Windows|0.276| |WELL_44497_A|Linux|0.294| |WELL_44497_A|Mac|0.328| |WELL_44497_A|Windows|0.306| |WELL_44497_B|Linux|0.297| |WELL_44497_B|Mac|0.322| |WELL_44497_B|Windows|0.273| |WELL_512_A|Linux|0.432| |WELL_512_A|Mac|0.426| |WELL_512_A|Windows|0.363| |XOR_SHIFT_1024_S|Linux|0.813| |XOR_SHIFT_1024_S|Mac|0.831| |XOR_SHIFT_1024_S|Windows|0.813| Test - Linux Ubuntu 16.04 LTS : Intel Xeon E5-1680 v3 3.2GHz : OpenJDK 1.8.0_181 - MacOS 10.13 : Intel Core i7 2.7GHz (laptop) : Java 1.8.0_131 - Windows 7 : Intel Core i7-2600 3.4 GHz (desktop) : Java 1.8.0_171 I will set up a PR to add the method to the Int and Long providers. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636788#comment-16636788 ] ASF GitHub Bot commented on RNG-57: --- GitHub user aherbert opened a pull request: https://github.com/apache/commons-rng/pull/11 RNG-57: Cache values for nextBoolean() and nextInt() AbstractIntProvider has been updated to cache a value for nextBoolean(). AbstractLongProvider has been updated to cache a value for nextBoolean() and nextInt(). You can merge this pull request into a Git repository by running: $ git pull https://github.com/aherbert/commons-rng improvement-RNG-57 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-rng/pull/11.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #11 commit 58afa68ebef161fa938c06ceed6bc324e8367e4a Author: aherbert Date: 2018-10-03T10:54:37Z RNG-57: Cache values for nextBoolean() and nextInt() AbstractIntProvider has been updated to cache a value for nextBoolean(). AbstractLongProvider has been updated to cache a value for nextBoolean() and nextInt(). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636813#comment-16636813 ] Alex D Herbert commented on RNG-57: --- The changes to implement the cache in {{IntProvider}} and {{LongProvider}}: [PR 11|https://github.com/apache/commons-rng/pull/11] Travis has just told me this failed. This is due to 'Too many failures ...' in the testing of the different providers. This is for code I have not touched as the tests are for IntProvider.nextInt() and LongProvider.nextLong(). I assume they would pass on repeat since they are random. Note that different provider tests failed for JDK 7, 8 and 9 due to randomness. There are also a failures for ProvidersCommonParametricTest.testStateSettable(). This has not been fixed and was intended to be part of a different PR. However it may be best implemented together to make the PR atomic. This will take a bit of time. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636816#comment-16636816 ] ASF GitHub Bot commented on RNG-57: --- Github user aherbert commented on the issue: https://github.com/apache/commons-rng/pull/11 This failed. This is partly due to 'Too many failures ...' in the testing of the different providers. This is for code I have not touched as the tests are for IntProvider.nextInt() and LongProvider.nextLong(). I assume they would pass on repeat since they are random. Note that different provider tests failed for JDK 7, 8 and 9 due to randomness. There are also a failures for ProvidersCommonParametricTest.testStateSettable(). This has not been fixed and was intended to be part of a different PR (see [RNG-57](https://issues.apache.org/jira/browse/RNG-57?focusedCommentId=16635531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16635531)). However it may be best implemented together to make the PR atomic. This will take a bit of time. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636981#comment-16636981 ] Gilles commented on RNG-57: --- {quote}There are also a failures for ProvidersCommonParametricTest.testStateSettable(). {quote} I haven't looked at the error yet, but tests related to the saving/restoring the state were expected to fail, weren't they? Until the whole state is taken into account... {quote}However it may be best implemented together to make the PR atomic. {quote} As you wish; but try to make incremental commits, separating the new "state saving" logic from the cache feature, as much as possible. Or let me the chance to implement the latter. ;) I may have some time tomorrow; but if you want to do it today, no problem... > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16637066#comment-16637066 ] Alex D Herbert commented on RNG-57: --- {quote}Or let me the chance to implement the latter.{quote} I was just thinking the same. If the state saving is separated into the abstract class and derived classes then this can be committed without error. My PR then just needs to be updated (and verified) when master has moved on. So I'll leave it until you have had a look at the state issue. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638968#comment-16638968 ] Gilles commented on RNG-57: --- bq. when master has moved on Please review the changes made for RNG-58. All tests pass, but there isn't any actual state yet other than at the bottom of the hierarchy... > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639023#comment-16639023 ] Gilles commented on RNG-57: --- Nit about PR 11: No need to insert paragraph formatting tags (...) in the Javadoc; in particular for private fields or methods (that won't appear in the generated doc for the web site). IMO, the tags are visual noise that makes it more difficult to read the source file. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639951#comment-16639951 ] Alex D Herbert commented on RNG-57: --- {quote}No need to insert paragraph formatting tags (...) in the Javadoc{quote} Thanks for pointing that out. I add them everywhere out of habit. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1663#comment-1663 ] Alex D Herbert commented on RNG-57: --- {quote}Please review the changes made for RNG-58. {quote} Nice modifications. I noticed that the {{BaseProvider}} has the signature: {code:java} protected byte[] composeStateInternal(byte[] state, byte[] parentState) { {code} but the javadoc order for {{parentState}} and {{state}} are reversed. So I assume you originally wrote it the other way around then swapped them. With no state from the parent it wouldn't be detected in a test. Suffice to say it doesn't work as is and I had to swap them back to: {code:java} protected byte[] composeStateInternal(byte[] parentState, byte[] state) { {code} This is the simplest change to get things working. However the order in the combined state is state+parentState so logically the arguments should be state and parentState. But all the sub-classes do this: {code:java} return composeStateInternal(super.getStateInternal(), state); {code} So parent should be first. It is also documented to work this way. So I've just added some comments in the code that the order is state+parent when combining and splitting. The test for {{ProvidersCommonParametricTest.testStateSettable}} passes. So the combining and splitting of the state is working. I am now getting some failures in {{ProvidersCommonParametricTest}} due to randomness. The failures are always the same. Each RNG is built using a fixed seed and I assume JUnit is running the tests in the same order. However the changes to cache calls from {{next}} (either {{int}} or {{long}}) means that the sequence that is tested after the first call to {{nextBoolean}} for an {{IntProvider}}, or the first call to {{nextBoolean/nextInt}} for an {{LongProvider}} is different. These are the failures: {noformat} [ERROR] Failures: [ERROR] ProvidersCommonParametricTest.testUniformNextIntegerInRange:165->checkNextIntegerInRange:400->checkNextIntegerInRange:420->checkNextInRange:552 org.apache.commons.rng.core.source32.MultiplyWithCarry256: Too many failures for n = 1834691456 (11 out of 500 tests failed) [ERROR] ProvidersCommonParametricTest.testUniformNextLongInRange:180->checkNextLongInRange:438->checkNextInRange:552 org.apache.commons.rng.core.source64.XorShift1024Star: Too many failures for n = 4611686018427387902 (11 out of 500 tests failed) {noformat} - MultiplyWithCarry256 is an {{IntProvider}} and so the method {{next(int)}} is unchanged. The failures are due to the state of the sequence being shifted after a call of nextBoolean. - XorShift1024Star is a {{LongProvider}} and the method {{next(int)}} has been changed. The failures may actually be due to the loss of randomness from using the using the upper and lower bits from the long as separate {{int}} samples. However both tests only fail with 11/500 (p=0.022) which is 1 failure above the critical p-value of 0.02. I've pushed to the same PR branch so you can view the changes. Q. What to do to fix this? - Change the fixed seed for each of the failing providers until it works. - Change the critical p-value. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640009#comment-16640009 ] ASF GitHub Bot commented on RNG-57: --- Github user aherbert commented on the issue: https://github.com/apache/commons-rng/pull/11 [RNG-58](https://issues.apache.org/jira/browse/RNG-58) addresses the setting of the state, allowing state to be stored at any level of the hierarchy below `BaseProvider`. This PR has been updated to use that functionality. The build now fails due to the randomness of testing. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640345#comment-16640345 ] Gilles commented on RNG-57: --- bq. So parent should be first. It is also documented to work this way. Actually not, as it would be confusing since in the code the "local" state comes first. bq. So I've just added some comments in the code that the order is state+parent when combining and splitting. Thanks but it is the Javadoc example that needed fixing. And all the calls in the implementations... As you noted, the code in {{BaseProvider}} concatenates "local" + "parent", and is pretty self-documenting. I'll make a separate commit to fix. Sorry for the mix-up! > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640357#comment-16640357 ] Gilles commented on RNG-57: --- Please rebase your changes on the current "master" (sorry). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640363#comment-16640363 ] Alex D Herbert commented on RNG-57: --- I also noticed that {{BaseProvider}} returns an empty array in {{getStateInternal}} but the method to concatenate them only checks for null. So the null check could be updated to: {code:java} if (parentState == null || parentState.length == 0) { return state; } {code} A quick check with: {noformat} mvn test jacoco:report {noformat} shows that the parentState == null is never hit at the moment. WDYT? > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640369#comment-16640369 ] Gilles commented on RNG-57: --- bq. Each RNG is built using a fixed seed IIRC, I did this to avoid a circular dependency between {{commons-rng-core}} and {{commons-rng-simple}}; but I think that a random seed would be preferable, even if the test would then sometimes fail. Perhaps a circular dependency in the {{test}} area is acceptable (?). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640372#comment-16640372 ] Gilles commented on RNG-57: --- bq. shows that the parentState == null is never hit at the moment. Indeed. I changed that yesterday but forgot to {{git push}}... It's now in "master". > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640375#comment-16640375 ] Alex D Herbert commented on RNG-57: --- bq. IIRC, I did this to avoid a circular dependency between commons-rng-core and commons-rng-simple; For a test you can use anything to create the seed, i.e. another library. The maven dependency can be scoped to test. But that adds complexity so just use java.util.Random to get a not so random seed. Or SecureRandom to get a very random one. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640379#comment-16640379 ] Alex D Herbert commented on RNG-57: --- bq. Please rebase your changes on the current "master" (sorry). Done. It still fails due to randomness on this machine on {{MultiplyWithCarry256}} with {{nextInt}}. I say this machine since it is now my laptop. I noticed that the errors on Travis were different for JDK 7 than with 8 & 9. I'm using JDK 8. So the JUnit tests must get run in a different order depending on the JDK and/or the platform. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640486#comment-16640486 ] Gilles commented on RNG-57: --- There are too many things in PR 11: it should only contain the additions to {{LongProvider}} and {{IntProvider}} and their associated unit tests. For the failures, I think that the least problematic change would be to select another seed. We can always revisit later the common infrastructure of the unit tests. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640697#comment-16640697 ] ASF GitHub Bot commented on RNG-57: --- Github user aherbert commented on the issue: https://github.com/apache/commons-rng/pull/11 This branch has too many commits. I am closing the PR and will create a new one from master. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640698#comment-16640698 ] ASF GitHub Bot commented on RNG-57: --- Github user aherbert closed the pull request at: https://github.com/apache/commons-rng/pull/11 > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640712#comment-16640712 ] Alex D Herbert commented on RNG-57: --- I've closed the PR and repeated the changes in a new branch. Do you want me to experiment with different seeds in {{ProvidersList}} until the tests pass? A quick change to add a few more numbers to the MWC_256 seed has fixed the test locally. Unfortunately travis may still fail as it runs JDK 7, 8 and 9 and locally passing tests on one machine may not transfer. I am wondering if the {{ProvidersList}} should make a better attempt at creating a full length seed. Perhaps this will make the test more robust. Previously the RNGs that failed were: ||RNG||Native seed||Test seed|| |Well1024a|int[32]|int[3]| |XorShift1024Star|long[16]|long[3]| |MersenneTwister|int[624]|int[3]| |MultiplyWithCarry256|int[257]|int[4]| So the seed could be made full length for each provider. Although each provider does expand the seed to the full length using a scrambling method the original seed could be improved using numbers that have more complete coverage of the bit size of the native seed type. The numbers typed into the test are quite short and may not contribute enough entropy. Using java.util.Random is an option. However I am not sure the implementation is guaranteed to return the same sequence for the same seed for all future JDK versions. So hardcoding the seed is probably better. WDYT? - Repeat the PR as is with it failing and leave {{ProvidersList}} for a different change? - Update the PR to include better seeds for {{ProvidersList}} Applying the code changes is easy. I can create a temp branch to try different seeds until it passes on Travis then formulate an atomic PR. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640722#comment-16640722 ] Alex D Herbert commented on RNG-57: --- Wow that test is hard to get to pass. I just tried this using a 1024 byte random seed for all tests. The seed is stored as a string and decoded using Commons Codec: {code:java} public class ProvidersList { /** List of all RNGs implemented in the library. */ private static final List LIST = new ArrayList(); /** List of 32-bits based RNGs. */ private static final List LIST32 = new ArrayList(); /** List of 64-bits based RNGs. */ private static final List LIST64 = new ArrayList(); /** * Provide a random byte seed encoded as a hex string (length must be even). * * 1024 bytes = 2048 hex characters. This provides 128 longs and 256 integers. */ private static final String HEX_SEED = "75d1fb070512e503f9635706318f2dabbd6e2120addbd50c8ff8272654f3082c" + "edf244845db03415bf661051d9a487c622b6411a6773596f459465c72d59e870" + "c6bd90089a6fb7294d3beea8feba7d8307745cbd1233b6f85ff0294f87483d9a" + "ea77939ced0eb7e41617b52ac5a0d32d49c456e7b4c2485bd8d8be990f626458" + "86c5194aa34eb1f83efc38808ebf1fcd813667f88e7a76191dee40f662968a8c" + "71cf6493497ad77e00efbb59bfbf9b7664f8c32b4f5f29064329174bbce4870d" + "bb6bfd683415428d1c2c76eacca237df7119ecf1e6eac7cc97f3548bb10255b0" + "74a44010fa4811fc622104cea4ca045c674bbaa65f2273879301c4902bdb2f72" + "b9e7b1f5414704bb240a6a4d490a39739a557338b1e58cb5e81d8157172482d0" + "407795dffa92caacf3db3c848e1f2962bd5e8ddd4691a49779eea65d38d9d584" + "9b7ea054677618a9f56893877c34bb5d928308c8be19e07627b646cc743d0ddf" + "44757e64c1268eeb5e88a55a718f4fb9ba313b68ab1729efff6989192c95a2d8" + "42292766523b8d03e2dc10b1157b45909ecf239e59a4334eafa0b48c39a980dc" + "0f4238dcdaf306a57a29758a23f992eb7d13439ad982ec5a83aac630a31e05a3" + "0724a7babb5ebbcc00144c90a9a79c976f7cdd516fd94a432e815e3aeffdccb0" + "515a409dcfe7f492c0015234706eff83eda607cf76ec9b0f74a6d3050fc1f469" + "42475ef814847c5053fffa1e5d732f8954f1d6a678ce88e19ca92f6d5b945ac3" + "f872c05f3481659f27f570f3d387e1a75bc17408d454c6b4190d78c6aeac2cc5" + "0d8042b373ca4f149e32b81933076c23c2e3e36d7ba29079dd0e605b617c6378" + "ee714b66cb0959f4ff127cf1f0ad42919780fc51174c8818a630d32bfca5b03c" + "698e63f774dc979a27dddc795d5146ab49baf32b79014bf2e533e82d663da5d8" + "42d57fbe1e1a270ccb17c6daf1ea6cad92a4f6b311dee23f5362106d0cda8130" + "ae391221e790a610b6bbd9f64bf988783a5fde4b0d3504a417aac0a1a70b8c4a" + "6395ae21e41c1efa31a37737b15d4c8c77909306c41028ea9e04d7f0141b2c13" + "d6e0d20a0df619b575eeb1c6aebd7f03b56060c4bf4cf1fdcea3f0a9d03d8e61" + "54d8d9c92fb5eba0f3f3ddaa82190c766d0c5acdc52b29cf4dfe45731434e443" + "8652301bbba00bad464a467abfe46283adfd05bffad627171140fbbbf6d080a0" + "9971e17c0771abe6e354eb2e3330449080cf2133ac5b4a4240c357c50b5b144b" + "7c8fd76935fbb2741b4def4ea7f2455d794e600a121d16172fc4c951ba152b89" + "99232249e456e47ed12270959e2d5ae97a73b6d448a958e9c644e51af7199ce8" + "ed6a277f88a599093214e70832fe52ebf99862ce2e59da603a909075c238a8cf" + "42f359f7d269716bf53fcd10e04f3149b55dafce78cc8d5f2753723b1a202d86"; static { try { // Decode the seed into bytes. byte[] bytes = Hex.decodeHex(HEX_SEED); // Create long seeds DataInputStream dis = new DataInputStream(new ByteArrayInputStream(bytes)); long[] longSeed = new long[bytes.length / 8]; if (longSeed.length < 10) { throw new Exception("Not enough seed bytes"); } for (int i = 0; i < longSeed.length; i++) { longSeed[i] = dis.readLong(); } dis.close(); // Create int seeds dis = new DataInputStream(new ByteArrayInputStream(bytes)); int[] intSeed = new int[bytes.length / 4]; for (int i = 0; i < intSeed.length; i++) { intSeed[i] = dis.readInt(); } dis.close(); // "int"-based RNGs. add(LIST32, new JDKRandom(longSeed[0])); add(LIST32, new MersenneTwister(intSeed)); add(LIST32, new Well512a(intSeed)); add(LIST32, new Well1024a(intSeed)); add(LIST32, new Well19937a(intSeed)); add(LIST32, new Well19937c(intSeed)); add(LIST32, new Well44497a(intSeed)); add(LIST32, new Well44497b(intSeed)); add(LIST32, new ISAACRandom(intSeed)); add(LIST32, new MultiplyWithCarr
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640723#comment-16640723 ] Gilles commented on RNG-57: --- bq. I am wondering if the ProvidersList should make a better attempt at creating a full length seed. As you note, the "scramble" method is supposed to avoid obvious pitfalls like the seed being mostly zeroes or other periodic set of bits. If only full length seeds were necessary to make tests that use a few generated numbers pass, I'd guess that it would indicate an expectation problem (thus change the test) or a dysfunctional RNG (thus fix the RNG). My preference would be to have the unit test run with different (random) seeds at each build. Junit can take care of repeating failing tests (called "flaky") but IIUC, it would only rerun a {{@test}} whereas in this case, it is the {{ProvidersList}} instance that must be reloaded. So this would imply moving the code from a {{static}} block to a regular constructor, and pass it to the unit test classes in a different way. Currently, I don't think this refactoring is worth the time and the possible drawbacks. bq. I can create a temp branch to try different seeds until it passes on Travis then formulate an atomic PR. Agreed; the first thing would be to "empirically" try a few seeds to ensure that the tests pass much more often than they fail. If that's the case; the stress tests suites will ensure (if the result are OK) that the cache did not degrade the quality of the randomness of {{nextInt()}}. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640855#comment-16640855 ] Alex D Herbert commented on RNG-57: --- I've had a look at {{ProvidersCommonParametricTest}} and why this fails. In summary the test runs the RNG to create a uniform sample using 1000 samples and tests it is uniform using a Chi squared test with a critical value at 1%. 500 repeat chi square tests are made and if more than 2% fail then this is a test fail. This is fair. I only found one bug in the test and that was a rounding error setting the range of the upper bin when the max was 2305843009213693951L (Long.MAX_VALUE / 4). It was out by 1 and so not a problem with a range this big and not the reason for the test being flaky. I did notice that the test is usually failing when the range under test is an integer range that is not a power of 2. So it may be failing because the test is checking not the randomness of the entire binary bits from the RNG but the algorithm for generating an integer that is not a power of two. This algorithm does not use the entire binary bits but is biased to using the least significant bits since it sets the returned value using the modulus of the binary bits using a rejection algorithm: {code:java} // Excerpt from BaseProvider.nextInt(int) do { bits = nextInt() >>> 1; // Here the bits returned are composed of the least // significant bits (bar one) from the random val = bits % n; } while (bits - val + (n - 1) < 0); {code} Since I have modified {{ProvidersCommonParametricTest}} to randomly seed each time I am running it 1000 times and logging the number of test fails for each test, e.g. {noformat} org.apache.commons.rng.core.source32.Well512a: Pass for n = 1234 (9 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 4 (0 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 10 (6 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 12 (8 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 31 (3 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 32 (4 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 2016128993 (2 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 1834691456 (7 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 869657561 (7 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 1570504788 (9 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 4 (0 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 11 (6 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 19 (5 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 31 (8 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 32 (4 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 2305843009213693951 (4 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 4611686018427387902 (9 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 6917529027641081853 (2 out of 500 tests failed) org.apache.commons.rng.core.source32.Well512a: Pass for n = 578 (3 out of 500 tests failed) {noformat} We expect to see 5 out of 500 tests failed. I am going to do some analysis on the output to see if the tests for non-power of two {{nextInt(int)}} and {{nextLong(long)}} are more flaky than the others. If correct then this may be solved by: - increasing the tolerance for those tests (i.e. >2% fail rate) - increasing the number of samples for those tests (i.e. >1000) - removing those tests and just using nextBytes[] The last idea or a modification of it is to just test the RNG produces an acceptable random stream of bits. Although fine for the current providers it would not cover future providers that may override nextFloat, nextDouble, nextInt(int), nextLong(long). > 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}}
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640891#comment-16640891 ] Alex D Herbert commented on RNG-57: --- Having though about this the simulation can be modelled as a Binomial distribution. Each Chi square test has a probability of failure of 0.01 (if the RNG is perfect). Here's the CDF for a Binomial(n=500, p=0.01): ||Number of failures (k)||CDF(x <= k)||1 - CDF(x <= k)|| |0|0.0066|0.9934| |1|0.0398|0.9602| |2|0.1234|0.8766| |3|0.2636|0.7364| |4|0.4396|0.5604| |5|0.6160|0.3840| |6|0.7629|0.2371| |7|0.8677|0.1323| |8|0.9329|0.0671| |9|0.9689|0.0311| |10|0.9868|0.0132| |11|0.9948|0.0052| |12|0.9981|0.0019| |13|0.9994|0.0006| |14|0.9998|0.0002| |15|0.|0.0001| |16|1.|0.| So the current limit of 10 will be exceeded at a rate of (1 - 0.9868) = 0.0132. To make the test robust the p-value for failure can be set at p=0.001. Then the limit would have to be 13 failures. If the RNG is not perfect then the Chi square test will fail more often than 1% of the time and this should easily be detected. I'll collate the results from testing each provider with random seeds and see what the failure rate would be for each at different failure thresholds. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641535#comment-16641535 ] Gilles commented on RNG-57: --- bq. what the failure rate would be for each Why should the number of expected failures be different for each algorithm? > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641616#comment-16641616 ] Alex D Herbert commented on RNG-57: --- bq. Why should the number of expected failures be different for each algorithm? Because they are not all perfect. The DieHarder results show that. The null hypothesis is that the RNG is perfect and the binomial distribution can be used to determine how many failures to expect for the repeated Chi square test. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641910#comment-16641910 ] Alex D Herbert commented on RNG-57: --- Apologies in advance for the long post. This stems from the desire to understand why my simple changes for RNG-57 have broken the test suite for commons-rng-core. I ran the {{ProvidersCommonParametricTest}} test 1000 times with a random seed generated by SecureRandom as a 1024 byte array. Code snippet to do this is posted in [#comment-16640722]. The raw data were large (>40MB) so I extracted the number of failures for each test and have uploaded this to my current PC. Unfortunately I produced the raw data incorrectly as the test stops at the first failure and later tests will be missing repeats. So for example this test for nextInteger has incomplete data because early tests fail: {code:java} @Test public void testUniformNextIntegerInRange() { checkNextIntegerInRange(4, 1000); checkNextIntegerInRange(10, 1000); checkNextIntegerInRange(12, 1000); // If this fails ... checkNextIntegerInRange(31, 1000); // Data for the remaining will be missing !!! checkNextIntegerInRange(32, 1000); checkNextIntegerInRange(2016128993, 1000); checkNextIntegerInRange(1834691456, 1000); checkNextIntegerInRange(869657561, 1000); checkNextIntegerInRange(1570504788, 1000); } {code} However the number of tests is always above 900 and so I did a Chi squared test to determine if the number of failures fits a Binomial distribution. Here are some demo results for the MWC_256 method. The table shows the method under test, the mean number of failures, the p-value from a chi squared test matching the histogram of failures to a Binomial and then a cumulative histogram of the number of failures. The final column value is the number of tests (sometimes less than 1000). |Method|Mean fails|p(Binomial(n,p=0.01)|Cumul Fails (X<=x\|x=0)|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15| |nextInteger(1834691456)|5.027|0.999|6|49|130|256|406|565|710|812|892|923|937|947|950|950|951| | |nextLong(6917529027641081853)|4.904|1|9|41|127|252|418|580|719|828|867|898|920|926|928| | | | |nextDouble()|4.928|0.989|8|42|131|265|446|633|772|876|940|973|989|998|999|1000| | | |nextInteger(32)|4.889|0.997|6|38|130|268|451|619|761|848|909|941|958|964|967|969| | | |nextInteger(10)|4.914|0.991|9|36|121|270|460|636|776|872|940|976|994|997|999|1000| | | |nextInteger(1570504788)|4.902|1|4|38|118|256|429|594|725|809|867|899|918|921|923|925|925|926| |nextInteger(2016128993)|4.98|1|6|39|110|230|428|585|749|839|900|935|951|954|957|958| | | |nextInteger(31)|4.969|0.996|9|40|132|265|450|606|753|839|901|952|969|975|979|980| | | |nextLong(31)|4.99|0.999|7|32|106|253|429|601|747|845|911|947|964|968|969|970|971| | |nextLong(4611686018427387902)|4.989|1|7|44|122|254|404|572|721|819|876|912|928|940|940|940|941| | |nextLong(32)|5.053|1|7|36|113|240|408|585|728|845|897|929|949|961|963|964| | | |nextInteger(12)|5.016|0.994|6|44|129|261|436|610|752|856|925|961|980|985|992|993|994| | |nextFloat()|4.953|0.991|8|42|129|261|428|625|777|878|949|974|984|994|998|1000| | | |nextLong(11)|4.922|0.991|7|36|135|272|440|631|776|890|940|973|986|995|997|1000| | | |nextLong(2305843009213693951)|5.046|1|1|33|109|241|401|582|704|826|894|924|941|945|947|949| | | |nextInteger(4)|0|0|1000| | | | | | | | | | | | | | | | |nextLong(4)|0|0|1000| | | | | | | | | | | | | | | | |nextLong(19)|4.977|0.997|5|37|130|271|448|620|744|855|915|948|971|983|984|986| | | |nextInteger(869657561)|4.918|1|5|33|98|252|409|599|749|831|886|915|926|934|936|937| | | Here are some conclusions: - Repeating the Chi squared test for uniformity 500 times with a critical p-value of 0.01 produces counts that can be modelled as a binomial distribution. - The mean is 5 (n*p = 500*0.01). - The test for nextInteger/Long(4) always passes. The test is performed using 10 bins and there only 4 discrete values. Basically the test is invalid and the Chi square test should be done using 3 degrees of freedom. - The test fail threshold of 10 allowed failures corresponds to a cumulative probability of 0.9868 (see [#comment-16640891]). This means it will fail 1.32% of the time. Note that currently there are 19 tests using this approach. We can discount 2 (nextInteger(4) and nextLong(4)) leaving 17. There are also 3 random walk tests with a 1% critical value on the range allowed and 2 tests for uniform next bytes using a single chi squared p-value of 1%. So for a single RNG the probability that no tests will fail is: {noformat} (1 - 0.0132)^17 * (1 - 0.01)^3 * (1 - 0.01)^2 = 0.7587 {noformat} The test is performed on 16 variants of the RNG. So the probability no tests will fail is: {noformat} 0.7587^16 = 0.0121 {noformat} This seems very low. I don't have data for the random walk
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642648#comment-16642648 ] Gilles commented on RNG-57: --- bq. Apologies in advance for the long post. A very interesting analysis (and a useful appendix to the user guide perhaps). Here on JIRA, it's not easy to follow the discussion (e.g. wide tables are not displayed in their entirety). Codes (that would produce the above tables) could go in the {{commons-rng-examples}} module. bq. An alternative approach would be to reduce the number of tests per RNG. These could be limited to nextBytes and either nextInt or nextLong depending on the type of provider. Did I understand correctly that you propose to # test the randomness uniformity of each of the implementations of {{IntProvider}} (resp. {{LongProvider}}) through exercising {{nextInt()}} (resp. {{nextLong()}}) only, and # test the rest of the methods defined in {{UniformRandomProvider}} using {{SecureRandom}} as the source? bq. It is not very convenient for local development though as builds will fail a fair amount. JUnit is set to rerun failing tests (once in the current config); it seems to work fine for module {{commons-rng-sampling}}, where the distribution tests do indeed use random seeds. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643062#comment-16643062 ] Alex D Herbert commented on RNG-57: --- bq. Did I understand correctly that you propose to Yes. The test suite should satisfy the aims: 1. Demonstrate each implementation is a valid Java port (if it is a port) 2. Demonstrate each implementation is an 'acceptable' source of randomness for int/long 3. Demonstrate each implementation can be saved and restored, no matter what the initial seed and current state 4. Demonstrate a source of randomness for int/long can be used to produce randomness for boolean, float, double and a range of int/long (i.e. the UniformRandomProvider interface) 5. Exercise all the code paths and expected edge case behaviour 6. Leave thorough statistical analysis of the randomness of each provider to the Big Crush test IMO the current test suite does this except for using random seeds to create the providers. However it over tests certain parts of the code due to repetition and due to the nature of the the tests this results in a high overall failure rate for the entire test suite. Currently each provider has a unit test that demonstrates the Java port of the algorithm is functioning as per the original source. Then each algorithm is used to provide either {{int}} or {{long}} as the base of all randomness. So unit test the base implementation of UniformRandomProvider for int/long once. This should be done using a very random source such as the strongest cryptographically secure algorithm in SecureRandom. Then unit test the construction edge cases and save/restore functionality of each provider. This can use random seeds to ensure a robust test suite. These tests should never fail. Then finally test the nextInt() and nextLong() methods of each provider only once. This can be created to have a known fail rate that is acceptable. E.g. use a single Chi squared test with a known fail rate, e.g. 1%. Or do repeated Chi squared test on small samples and then test the results follow a Binomial distribution with a p of 0.01. For simplicity a single Chi squared test of a long run of the provider sequence would be my choice. The test for nextInt or nextLong can either compress all the bits into bytes for a 256 bin histogram for the Chi square test or use a 1024 bin histogram for int (4 * 256 bins with each set coming from a 8-bit block of the integer) and 2048 bins for long. Currently the tests for nextInt/Long/Float/Double use 1000 samples repeated 500 times in 19 individual test runs. That is 9,500,000 samples. This could be compressed into a single test. If this was set to 1,024,000 samples a uniform distribution over 2048 bins would have 500 samples per bin. This would run 9 times faster than the current test suite and should fail at a known rate, e.g. 1%. Allowing each test to be repeated 1 time by JUnit in event of failure will then cause the fail rate to drop to (0.01)^2, or 0.01% of the time. With 16 providers the likelihood of a failure of all providers is low and the likelihood of a pass of all 16 is: {noformat} (1 - 0.0001)^16 = 0.998 {noformat} So if failed tests can be repeated just once you will see Travis jobs failing 0.2% of the time. This assumes each RNG provider is perfect and will fail exactly 1% of the time. I'd then suggest some data collation of failures be performed over a long period. Each RNG should fail 1% of the time but this can be examined when the suite has been run a few thousand times by Travis. Such data can be collated periodically and could form a page for the user guide. > 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
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643160#comment-16643160 ] Gilles commented on RNG-57: --- bq. The test suite should satisfy the aims I'm fine with further consolidating the unit test suite. Would you write it out in a new section of the [user guide|https://git1-us-west.apache.org/repos/asf?p=commons-rng.git;a=blob;f=src/site/apt/userguide/rng.apt;h=8ae6f92910dc99c921ee84809ebe6ae3b7357116;hb=HEAD] (as section "5. Unit testing", moving the current "5. Quality" to "6. External testing")? bq. tests for nextInt/Long/Float/Double \[...\] could be compressed into a single test. How would a single test detect which of the {{NumberFactory}} methods were buggy? bq. can be examined when the suite has been run a few thousand times by Travis. Why not run locally? > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643229#comment-16643229 ] Alex D Herbert commented on RNG-57: --- bq. How would a single test detect which of the NumberFactory methods were buggy? The {{NumberFactory}} is used in the base implementation of {{UniformRandomProvider}} by {{IntProvider}} or {{LongProvider}}. I suggested that is tested once for all methods using e.g. SecureRandom as the source. No need to test this for each provider. It is also used in the save/restore state functions by each provider and that will still be tested for each provider. bq. Why not run locally? No reason. Good catch. I was thinking that it would be nice to collate results over a large number of tests. However it would be better to do it once with a snapshot of the code. Using results from Travis for each build will end up polluting the results over time if code changes are made to the core providers. My test for 1000 repeats of the test suite took about 4 hours on my laptop. So it is easy to run overnight and get some reasonable statistics. bq. Would you write it out in a new section of the user guide OK. Sounds like tickets for the following: - Improvement: Add details of RNG testing to the user guide. This outlines the the aim of the test suite and provides a table of results for the number of times each RNG provider fails. This can be run locally before a release, or when the core module is updated. - Improvement: Refactor the tests for the core module to allow use of random seeds. Improve robustness of the tests using targeted testing of the random sequence of each provider allowing the test to fail under given statistical assumptions. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688792#comment-16688792 ] Alex D Herbert commented on RNG-57: --- A post to the commons developers list mentioned a release for v1.2 with this as the last outstanding issue. I am not sure my reply to the mailing list is published so I repeat is here: === The speed improvement has been demonstrated. However the effect on the randomness has not been tested using the 3rd party DieHarder and BigCrush test suites. I would be reluctant to change the core library without verifying the impact of the change. A second issue is that the change causes the current test suite to fail. As explained in this thread this is due to the high number of tests with a 1% acceptance level. Basically after enough tests for randomness something will almost certainly fail. The current test suite is expected to (and does) fail over 98% of the time with random seeds. It currently uses fixed seeds that work. Ideally the suite would work with random seeds and use a more selective set of tests (to reduce the chance for failures) but I have not had time to look at reengineering the test suite. It may be better to delay this for a later release. === Is there a guide for how to run DieHarder and BigCrush? I can do that with the changes and post the results. That should at least verify that the speed improvement has not broken the {{nextInt}} functionality of the {{LongProvider}}. If the change is OK then work should be done to make the test suite more robust as outlined in comment [#16643062], e.g.: - Change to test each provider only once for the {{int}} or {{long}} source of randomness - Change to test the underlying implementation of the {{UniformRandomProvider}} interface once for the {{int}} or {{long}} random source Once complete then this change can be put into a PR. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688914#comment-16688914 ] Gilles commented on RNG-57: --- bq. Is there a guide for how to run DieHarder There is a {{RandomStressTester}} Java application class under directory {{commons-rng-examples/examples-stress}}. It can start the "dieharder" program (to be installed separately). See the comments in the Java file. bq. and BigCrush? There is a little "bridge", in C, under {{commons-rng-examples/examples-stress/src/main/c}}. After compiling it (after having installed "TestU01" separately), it can be run through the above Java application. bq. make the test suite more robust I've created RNG-60 as step in that direction (and perhaps it will be "good enough"). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689433#comment-16689433 ] Alex D Herbert commented on RNG-57: --- Using RNG-60 I have made the same changes that previously failed and they now pass. Do you want a PR to see the changes? > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689499#comment-16689499 ] Alex D Herbert commented on RNG-57: --- BigCrush I manged to get this to work using: {code:java} > sudo aptitude install libtestu01 libtestu01-dev testu01-bin > cd commons-rng-examples/examples-stress > gcc src/main/c/stdin2testu01.c -ltestu01 -ltestu01mylib -ltestu01probdist -o > stdin2testu01 {code} DieHarder {code:java} > sudo aptitude install dieharder {code} RandomStressTester I modified examples-stress/pom.xml to use the maven shade plugin to build the examples.jar. These changes could be put into a PR so they make running the tests easier. I can now run DieHarder and BigCrush. How long should they take? Is this an overnight job? > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689506#comment-16689506 ] Gilles commented on RNG-57: --- bq. Do you want a PR to see the changes? Yes! > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689530#comment-16689530 ] Gilles commented on RNG-57: --- bq. PR so they make running the \[stress\] tests easier. Yes, please. Could the "shade" plugin config be shared for making it easy to run all the examples that contain a {{main}} method (see RNG-29)? bq. I can now run DieHarder and BigCrush. How long should they take? Is this an overnight job? Durations are output at the end of the run; see the output files in the [user guide|http://commons.apache.org/proper/commons-rng/userguide/rng.html#a5._Quality]. Depending on the RNG under test, * a "Dieharder" run takes from about 100 to 250 minutes, * a "BigCrush" run takes from about 500 to 2000 minutes, per RNG. I'd guess that's the reason there are 3 suites in TestU01... Do you have a big cluster? :) > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689582#comment-16689582 ] Alex D Herbert commented on RNG-57: --- bq. Could the "shade" plugin config be shared for making it easy to run all the examples that contain a main method I'm not sure. I just wanted to get it to work within my local branch so Maven collected the dependencies from the local repo (i.e. ran my new code). I'm not sure if the final shaded jar can be the final output artifact that can be pushed up to Maven central. It contains all the dependencies and Maven central may want them to have signed source files. Maybe it can be pushed as a binary artifact. I'm not familiar with distributed binaries. bq. Do you have a big cluster? Yes. But it's probably not necessary. I'd have to get DieHarder and testu01 installed as loadable modules on the cluster. 2000 minutes is 33.3 hours. I can run the tests over the weekend on an old workstation with 12 cores. I only have 4 {{LongProvider}}s to test. The {{IntProvider}}s have only changed {{nextBoolean}} and this is not tested. So 12 cores may be enough for 3 repeats of each test suite. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689734#comment-16689734 ] ASF GitHub Bot commented on RNG-57: --- GitHub user aherbert opened a pull request: https://github.com/apache/commons-rng/pull/12 RNG-57: Cache values for provision of nextBoolean and nextInt This PR contains the suggested changes to implement a cache to speed up the `nextInt` and `nextBoolean` methods in the core provider implementations. These changes improve performance but the effect on the `nextInt` method of `LongProvider` is unknown. A repeat of the DieHarder and TestU01 test suites is currently in progress. You can merge this pull request into a Git repository by running: $ git pull https://github.com/aherbert/commons-rng improvement-RNG-57 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-rng/pull/12.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #12 commit 91a5eec2d8a3318cf8fc8e6d222ac3edf3a0d969 Author: aherbert Date: 2018-11-16T13:10:51Z RNG-57: Cache values for provision of nextBoolean and nextInt > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689751#comment-16689751 ] ASF GitHub Bot commented on RNG-57: --- Github user coveralls commented on the issue: https://github.com/apache/commons-rng/pull/12 [![Coverage Status](https://coveralls.io/builds/20148825/badge)](https://coveralls.io/builds/20148825) Coverage decreased (-0.2%) to 97.358% when pulling **91a5eec2d8a3318cf8fc8e6d222ac3edf3a0d969 on aherbert:improvement-RNG-57** into **0fdcd9007c708aa48f1989cb2211ea56c1fcd702 on apache:master**. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16691772#comment-16691772 ] Alex D Herbert commented on RNG-57: --- I have the results of DieHarder and BigCrush for the {{LongProvider}} RNGs. Parsing DieHarder is easy. Just count FAILED except for the diehard_sums test. Parsing BigCrush I just count the number of failed tests in the summary at the end. I have found discrepancies in the [user guide|https://commons.apache.org/proper/commons-rng/userguide/rng.html] table for the current results. Here is what I find: ||RNG identifier||Dieharder||TestU01 (BigCrush)|| |JDK|14 16 15|78 75 76| |MT|0 0 0|2 2 2| |WELL_512_A|0 0 0|6 6 6| |WELL_1024_A|0 0 0|4 4 5| |WELL_19937_A|0 0 0|2 3 4| |WELL_19937_C|0 0 0|2 2 2| |WELL_44497_A|0 0 0|3 3 2| |WELL_44497_B|0 0 0|2 2 3| |ISAAC|0 0 0|1 0 0| |MT_64|0 0 0|2 2 3| |SPLIT_MIX_64|0 0 0|0 0 0| |XOR_SHIFT_1024_S|0 0 0|0 0 0| |TWO_CMRES|0 1 0|0 0 0| |MWC_256|0 0 0|0 0 0| |KISS|0 0 0|0 1 0| * WELL_1024_A is wrong for BigCrush (the user guide states 4,6,5) * WELL_1024_A and WELL_44497B are wrong for Dieharder as the diehard_sums test failure is not ignored Here are the results from the modified {{LongProvider}} RNGs: ||RNG identifier||Dieharder||new||TestU01 (BigCrush)||new|| |MT_64|0 0 0|0 0 0|2 2 3|3 4 3| |SPLIT_MIX_64|0 0 0|0 0 0|0 0 0|0 1 0| |XOR_SHIFT_1024_S|0 0 0|0 0 0|0 0 0|0 0 0| |TWO_CMRES|0 0 0|1 1 1|0 0 0|0 0 1| So the change has made the RNGs slightly worse with the exception of XOR_SHIFT_1024_S, which still has no failures. Here's a breakdown of the failed tests: ||RNG identifier||Test||Old||New|| |MT_64|BigCrush LinearComp, r = 0|3|3| |MT_64|BigCrush LinearComp, r = 29|3|3| |MT_64|BigCrush HammingIndep, L=300, r=0|1|0| |MT_64|BigCrush CollisionOver, t = 14|0|1| |MT_64|BigCrush SampleProd, t = 16|0|1| |MT_64|BigCrush RandomWalk1 H (L=1, r=15)|0|1| |MT_64|BigCrush RandomWalk1 J (L=1000, r=0)|0|1| |SPLIT_MIX_64|BigCrush ClosePairs mNP2, t = 9|0|1| |TWO_CMRES|diehard_dna|0|3| |TWO_CMRES|BigCrush RandomWalk1 C (L=50, r=25)|0|1| * MT_64 is still bad at the LinearComp test. This tests complexity of each successive bit from the bit sequence. It also fails the CollisionOver test which tests the uniformity of overlapping tuples from the sequence. So the MT_64 sequence is not random when compared to parts of itself. It also fails the SampleProd test that uses the entire bit sequence. Perhaps this RNG should be avoided. Note however that the new failures are just outside the allowed p-values. The LinearComp test fails with p < 1e-15 compared to the allowed 0.001. * SPLIT_MIX_64 fails a test using the entire bit sequence. The failure is p=0.9996 which is just outside p=0.9990. This is marginal fail. * TWO_CMRES is now bad at the diehard_dna test. This is marked as suspect in the version I installed (3.31.1) and perhaps these should be ignored. Failures on the RandomWalk tests (MT_64, TWO_CMRES) of BigCrush are interesting. According to the user guide (p.120) [http://simul.iro.umontreal.ca/testu01/guideshorttestu01.pdf] the walk of _{{L}}_ steps is performed using _{{s}}_ bits from each random {{int}} after dropping _{{r}}_ bits. So the {{RandomWalk r=0}} test is actually testing the new implementation of {{nextBoolean}} which obtains booleans using all the bits from a random sample. The results show a few failures in this test with the new implementation. The test is more rigorous than the random walk test in the core module as it tests the number of sign changes during the walk from zero and the time spent on each side. A failure of this test shows that the cached {{nextBoolean}} is not robust. Note that the failures are marginal: {noformat} 79 RandomWalk1 H (L=1, r=15) 6.9e-4 76 RandomWalk1 J (L=1000, r=0) 4.1e-4 75 RandomWalk1 C (L=50, r=25) 7.5e-4 {noformat} Mean run times (in minutes): Old: ||RNG identifier||Dieharder||TestU01 (BigCrush)|| |JDK|268.68 +/- 24.12|1918.44 +/- 10.08| |MT|189.15 +/- 3.26|1837.33 +/- 20.28| |WELL_512_A|195.51 +/- 6.70|1827.63 +/- 5.55| |WELL_1024_A|101.55 +/- 4.76|1864.89 +/- 24.80| |WELL_19937_A|108.35 +/- 6.14|1914.86 +/- 14.91| |WELL_19937_C|122.08 +/- 7.79|1922.84 +/- 8.42| |WELL_44497_A|111.41 +/- 3.44|1923.36 +/- 10.69| |WELL_44497_B|112.22 +/- 2.57|1926.86 +/- 33.81| |ISAAC|105.32 +/- 0.85|1837.63 +/- 10.47| |MT_64|101.64 +/- 2.94|1819.06 +/- 19.88| |SPLIT_MIX_64|96.12 +/- 4.80|480.92 +/- 19.77| |XOR_SHIFT_1024_S|99.05 +/- 3.46|508.50 +/- 5.06| |TWO_CMRES|105.38 +/- 4.22|502.01 +/- 9.68| |MWC_256|105.99 +/- 13.19|490.15 +/- 4.02| |KISS|75.80 +/- 3.61|487.72 +/- 7.65| New: ||RNG identifier||Dieharder||TestU01 (BigCrush)|| |MT_64|102.30 +/- 2.27|1355.75 +/- 10.52| |SPLIT_MIX_64|101.80 +/- 1.56|1336.16 +/- 12.60| |XOR_SHIFT_1024_S|107.09 +/- 5.47|1344.89 +/- 12.96| |TWO_CMRES|108.57 +/- 6.24|1341.70 +/- 13.50| The BigCrush algorithm was run on an old 1
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693722#comment-16693722 ] Gilles commented on RNG-57: --- bq. WELL_1024_A is wrong for BigCrush (the user guide states 4,6,5) Typo indeed. bq. WELL_1024_A and WELL_44497B are wrong for Dieharder as the diehard_sums test failure is not ignored The table shows all failures, to be consistent with the output from the software; 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. bq. The changes to use cached values slightly increase the number of failures How do you draw that conclusion? I'd think that some of the results are different because the seed/sequences are different. I'll commit the new result files (for all RNGs). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693792#comment-16693792 ] ASF GitHub Bot commented on RNG-57: --- Github user asfgit closed the pull request at: https://github.com/apache/commons-rng/pull/12 > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693829#comment-16693829 ] Gilles commented on RNG-57: --- bq. I'll commit the new result files Done. We should also update the benchmarks. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694613#comment-16694613 ] Alex D Herbert commented on RNG-57: --- {quote}I'll commit the new result files {quote} Done. I see that you have already re-run all the results and updated {{master}}. Do you still want my re-run? > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694670#comment-16694670 ] Alex D Herbert commented on RNG-57: --- {quote}we provide a robust script that will start "DieHarder" and "[Big]Crush" {quote} I already had to write a script to parse the output and generate a table for this ticket. Surely you also have scripts that you are using to create the user guide? I was going to submit the changes I made to {{examples-stress}} to build the shaded jar file as a PR. I could add my scripts. However they are far from robust. If this is a desired output, e.g. for RNG-29, then some more work should be done to make the executable jar files with a {{main}} a bit more user friendly, e.g. a decent help message. {quote}What can we conclude from that? {quote} Not much. The dieharder_dna test is marked as suspect anyway. Literally it would mean do not use that RNG to generate 4 letter DNA sequences using consecutive 2-bit letters from the {{int}}. This does have implications for the {{StringSampler}} discussed in RNG-54 since that is exactly what was discussed (for any power of 2 alphabet). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694802#comment-16694802 ] Gilles commented on RNG-57: --- {quote}Surely you also have scripts {quote} Yes, but it's all semi-manual: generating a JAR with all dependencies (from a different POM), a script to start the runs, another to print out the number of failures, copying/pasting each of them to the userguide. Tedious and not robust (typos and all). {quote}for RNG-29, then some more work should be done {quote} Indeed. But the question is whether either you or I want to devote a lot of CPU time to a massive run (see a [report|http://xoshiro.di.unimi.it/#shootout] from 100 runs). Time might be better spent porting other RNGs (e.g. newer algorithms provided at the above site). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694881#comment-16694881 ] Alex D Herbert commented on RNG-57: --- {quote}generating a JAR with all dependencies (from a different POM){quote} Using the shade plugin to generate the jar with all the dependencies is easy. I'll do a PR for that. I can put in my scripts to parse the output. You can always remove them. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694903#comment-16694903 ] Gilles commented on RNG-57: --- bq. shade plugin \[...\] PR Thanks. bq. I can put in my scripts Better different PR for different things. Scripts can be attached to a new JIRA issue, perhaps as a starting point towards something more "integrated" (auto-generated reports). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695468#comment-16695468 ] Gilles commented on RNG-57: --- I'm worried by the {{nextBoolean}} benchmark result: {noformat} *--*+ || RNG identifier || Score ratio | *--*+ | MWC_256 |0.89062 | *--*+ | MT |0.90006 | *--*+ | KISS |0.90939 | *--*+ | WELL_44497_B |0.93249 | *--*+ | WELL_19937_A |0.93395 | *--*+ | WELL_44497_A |0.93663 | *--*+ | ISAAC|0.94705 | *--*+ | WELL_512_A |0.94886 | *--*+ | WELL_19937_C |0.95391 | *--*+ | WELL_1024_A |0.96226 | *--*+ | JDK |1.0 | *--*+ | SPLIT_MIX_64 |1.04807 | *--*+ | TWO_CMRES|1.05701 | *--*+ | MT_64|1.08643 | *--*+ | XOR_SHIFT_1024_S |1.08982 | *--*+ {noformat} > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695743#comment-16695743 ] Alex D Herbert commented on RNG-57: --- bq. I'm worried by the nextBoolean benchmark result It seems to be as expected. {{nextBoolean}} is now caching an {{int}} or {{long}} value and then using it 32 or 64 times to generate a boolean. So all the providers will be approximately the same speed as the sequence generation is only called every 32nd or 64th call to {{nextBoolean}}. This basically levels the times. The {{LongProviders}} are slower due to the use of {{long}} bit shifts instead of {{int}}. I did experiment with allowing the {{LongProvider}} to cache a {{long}} value split in half for two {{int}} values that could be used to {{int}} bit shifts within {{nextBoolean}}. However this added overhead that lowered performance below just using {{long}} bit shifts. A good normalisation time would be to add a call to {{nextInt}} for the JDK generator. This will show that all providers are fast for generating booleans. I had a look at the the link you sent about the xoshiro benchmark of 100 runs. They conclude that if an RNG fails all 100 runs then it is a systematic failure. We do not have 100 runs but do have 9. There are the original 3 runs for {{IntProvider}} and the 3 new runs you have done. I have also done 3 runs for {{IntProvider}} but this is still pending. You have 3 runs for the new implementation of {{LongProvider}} and I have 6. I am building a script to look for systematic failures in this set of results. A systematic failure of {{nextInt}} in a test would indicate that the bit source output by the RNG is not suitable for caching. So any RNG that systematically fails should be reverted back to the original code. This will just require an {{@Override}} of the underlying implementation in the base class. This of course depends on the test that is systematically failing. However as described above the tests for LinearComplexity and RandomWalk are demonstrations that the entire bit sequence is not sequentially random. To err on the safe side it may be best to revert any RNG that systematically fails any test. So this would include JDK, the MT and MT_64 (fails LinearComp) and the new implementation of TWO_CMRES which always fails dieharder_dna. The xoshiro site indicates that WELL_1024_A fails LinearComp as well. I'll post the systematic failures report when the results are complete. > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695792#comment-16695792 ] Gilles commented on RNG-57: --- bq. The LongProviders are slower due to the use of long bit shifts instead of int. I vaguely imagined that could be the reason, but thought that, on a 64-bit machine, they might have had the same performance. bq. A good normalisation time would be to add a call to nextInt for the JDK generator. I'd prefer to keep the "same" reference, to compare the generators among themselves. bq. To err on the safe side it may be best to revert any RNG that systematically fails any test. I'm not sure: What ensures that the previous implementation to retrieve a boolean from the underlying RNG is better? Or, IOW, is there something that says that we cannot assume that the sequence of bits is not uniform? As a last resort, a user can perform a home-made combination of the RNG output in order to get a more (?) random {{boolean}}. It would be interesting to show an application failing because of lack of randomness of the sequence returned by the current implementation... bq. TWO_CMRES which always fails dieharder_dna But you said that the test might be "suspect". So, I'd rather keep the performance improvement, and trust the "BigCrush" results (that show no systematic failure for TWO_CMRES). > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695893#comment-16695893 ] Alex D Herbert commented on RNG-57: --- {quote}I'm not sure: What ensures that the previous implementation to retrieve a boolean from the underlying RNG is better? {quote} I'd not considered this. The only way to know would be to test it. This could be done by targeting the specific tests for RandomWalk within BigCrush using only the first bit (i.e. dropping all the other bits). This is possible using the C library API. Or build a RNG that composes an {{int}} using 32 calls to the underlying source using the upper bit from each source. This could be tested using the existing framework with all the test suites. It is simpler to just advise against using poor RNGs and stick to those with low errors from BigCrush. For systematic errors I have ignored dieharder_sums. I store a failure in each occurrence of the same test. For BigCrush the test has a test Id. This is the same even though the test may have multiple parts, e.g. this is one test failure: {noformat} 74 RandomWalk1 H (L=50, r=0)eps 74 RandomWalk1 M (L=50, r=0)eps 74 RandomWalk1 J (L=50, r=0)eps 74 RandomWalk1 R (L=50, r=0)eps 74 RandomWalk1 C (L=50, r=0)eps {noformat} For Dieharder the test has a name then a parameter (ntup), e.g. this is two tests: {noformat} rgb_lagged_sum| 14| 100| 100|0.95188466| PASSED rgb_lagged_sum| 15| 100| 100|0.| FAILED {noformat} Here's the old systematic failures table using the original txt results files for the {{LongProviders}}: ||RNG identifier||Test suite||Systematic failures||Fails|| |MT_64|TestU01 (BigCrush)|80:LinearComp|3/3| |MT_64|TestU01 (BigCrush)|81:LinearComp|3/3| Here's the new systematic failures table: ||RNG identifier||Test suite||Systematic failures||Fails|| |MT_64|TestU01 (BigCrush)|80:LinearComp|9/9| |MT_64|TestU01 (BigCrush)|81:LinearComp|9/9| |TWO_CMRES|Dieharder|diehard_dna:0|9/9| So as stated previously the TWO_CMRES is now failing a Dieharder test that is marked as suspect. No other RNGs have changed to systematic failure. FYI for the {{IntProviders}}: ||RNG identifier||Test suite||Systematic failures||Fails|| |JDK|Dieharder|diehard_oqso:0|9/9| |JDK|Dieharder|diehard_dna:0|9/9| |JDK|Dieharder|rgb_minimum_distance:3|9/9| |JDK|Dieharder|rgb_minimum_distance:4|9/9| |JDK|Dieharder|rgb_minimum_distance:5|9/9| |JDK|Dieharder|rgb_lagged_sum:15|9/9| |JDK|Dieharder|rgb_lagged_sum:31|9/9| |JDK|Dieharder|dab_bytedistrib:0|9/9| |JDK|Dieharder|dab_filltree:32|9/9| |JDK|TestU01 (BigCrush)|1:SerialOver|9/9| |JDK|TestU01 (BigCrush)|3:CollisionOver|9/9| |JDK|TestU01 (BigCrush)|5:CollisionOver|9/9| |JDK|TestU01 (BigCrush)|7:CollisionOver|9/9| |JDK|TestU01 (BigCrush)|9:CollisionOver|9/9| |JDK|TestU01 (BigCrush)|11:CollisionOver|9/9| |JDK|TestU01 (BigCrush)|13:BirthdaySpacings|9/9| |JDK|TestU01 (BigCrush)|14:BirthdaySpacings|9/9| |JDK|TestU01 (BigCrush)|15:BirthdaySpacings|9/9| |JDK|TestU01 (BigCrush)|16:BirthdaySpacings|9/9| |JDK|TestU01 (BigCrush)|17:BirthdaySpacings|9/9| |JDK|TestU01 (BigCrush)|18:BirthdaySpacings|9/9| |JDK|TestU01 (BigCrush)|19:BirthdaySpacings|9/9| |JDK|TestU01 (BigCrush)|20:BirthdaySpacings|9/9| |JDK|TestU01 (BigCrush)|21:BirthdaySpacings|9/9| |JDK|TestU01 (BigCrush)|22:ClosePairs|9/9| |JDK|TestU01 (BigCrush)|23:ClosePairs|9/9| |JDK|TestU01 (BigCrush)|24:ClosePairs|9/9| |JDK|TestU01 (BigCrush)|25:ClosePairs|9/9| |JDK|TestU01 (BigCrush)|26:SimpPoker|9/9| |JDK|TestU01 (BigCrush)|28:SimpPoker|9/9| |JDK|TestU01 (BigCrush)|30:CouponCollector|9/9| |JDK|TestU01 (BigCrush)|31:CouponCollector|9/9| |JDK|TestU01 (BigCrush)|34:Gap|9/9| |JDK|TestU01 (BigCrush)|36:Gap|9/9| |JDK|TestU01 (BigCrush)|40:Permutation|9/9| |JDK|TestU01 (BigCrush)|41:Permutation|9/9| |JDK|TestU01 (BigCrush)|42:Permutation|9/9| |JDK|TestU01 (BigCrush)|43:Permutation|9/9| |JDK|TestU01 (BigCrush)|44:CollisionPermut|9/9| |JDK|TestU01 (BigCrush)|45:CollisionPermut|9/9| |JDK|TestU01 (BigCrush)|46:MaxOft|9/9| |JDK|TestU01 (BigCrush)|47:MaxOft|9/9| |JDK|TestU01 (BigCrush)|48:MaxOft|9/9| |JDK|TestU01 (BigCrush)|49:MaxOft|9/9| |JDK|TestU01 (BigCrush)|50:SampleProd|9/9| |JDK|TestU01 (BigCrush)|51:SampleProd|9/9| |JDK|TestU01 (BigCrush)|52:SampleProd|9/9| |JDK|TestU01 (BigCrush)|57:AppearanceSpacings|9/9| |JDK|TestU01 (BigCrush)|59:WeightDistrib|9/9| |JDK|TestU01 (BigCrush)|62:WeightDistrib|9/9| |JDK|TestU01 (BigCrush)|63:WeightDistrib|9/9| |JDK|TestU01 (BigCrush)|65:SumCollector|9/9| |JDK|TestU01 (BigCrush)|74:RandomWalk1|9/9| |JDK|TestU01 (BigCrush)|86:LongestHeadRun|9/9| |JDK|TestU01 (BigCrush)|90:HammingWeight2|9/9| |JDK|TestU01 (BigCrush)|95:HammingIndep|9/9| |JDK|TestU01 (BigCrush)|97:HammingIndep|9/9| |JDK|TestU01 (BigCrush)|99:HammingIndep|9/9| |JDK|TestU01 (BigCrush)|101:Run|9/9| |MT|TestU01 (BigCrush)|80:Line
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16697756#comment-16697756 ] Gilles commented on RNG-57: --- No obvious regression was caused by implementing your proposal (cache). By using all the generated bits, it made it harder to pass all the tests (maybe that's why TWO_CMRES now fails one consistently). The refined testing which you suggest, and more extensive statistics can be done as part of a new issue (or a side project). Can we resolve this issue? > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699486#comment-16699486 ] Alex D Herbert commented on RNG-57: --- bq. Can we resolve this issue? Yes. (I have been away so sorry for delayed reply.) > 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[ https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700264#comment-16700264 ] Gilles commented on RNG-57: --- bq. sorry for delayed reply. No problem. Thank you for the thoughtful contribution. > 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)