commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Herbert <alex.d.herb...@gmail.com>
Subject Re: [Rng] New XoShiRo generators
Date Fri, 15 Mar 2019 18:00:46 GMT


> On 15 Mar 2019, at 17:37, Gilles Sadowski <gilleseran@gmail.com> wrote:
> 
> Hi Alex.
> 
> Le ven. 15 mars 2019 à 14:08, Alex Herbert <alex.d.herbert@gmail.com> a écrit
:
>> 
>> FYI.
>> 
>>> I am going to update stdin2testu01.c so that it passes all the input bits to
TestU01 and try again.
>>> 
>>> I’ve read some of the code and manual of TestU01 and the values that are returned
from the unif01_Gen->GetBits method (unsigned long) are assumed to be 32-bit unsigned.
So I think just changing stdin2testu01.c to read the buffer using uint32_t should work.
>>> 
>> 
>> When reading the stdin using a uint32_t for BigCrush I am already seeing a lot of
failures for the composites.
> 
> Thanks for the update.
> It's not clear to me why the other version of the interfacing code
> would be more forgiving.
> 

The benchmark program RandomStressTester exclusively uses nextInt() to write to the output.

This is read by dieharder which directly reads from stdin. This worked to collect all the
generated bits and the serial and xor composites failed the test suite.

It is also read by the stdin2testu01.c program to pass to TestU01.

What is happening is that the stdin2testu01.c is reading 64-bits using an unsigned long. This
is then cast to an unsigned int at 32-bits and given to TestU01. This leads to loss of 32-bits
of information.

So every second int from the RNG nextInt() method is ignored. 

This means that the serial composite I created that was testing alternate generators was in
fact only testing one generator as all the ints from the second generator were skipped.

It does not however explain why the xor composite passed (with a few failures) as this would
have an int created from a xor of both generators. However the composite ints would still
have every second sample discarded so the xor was testing a xor of the upper 32-bits of the
long from each generator. This had enough variability to pass the tests. The lower 32-bits
(which Dieharder was also using) may not.

Anyway the serial tests are now about 2/3 of the way through and there are currently the following
rough counts of failures:

grep -c '  \*\*\*\*\*' serial_* xor*
serial_1:85
serial_2:64
serial_3:82

Lots. The xor composite has been stalled on the current test (no more output) for the last
6 hours. So the generator takes a long time to be tested although I’m not sure why.

> Gilles
> 
>> 
>> Results should be complete before the end of today.
>> 
>> Alex
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message