> On 15 Mar 2019, at 17:37, Gilles Sadowski <gillese...@gmail.com> wrote: > > Hi Alex. > > Le ven. 15 mars 2019 à 14:08, Alex Herbert <alex.d.herb...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
