Hi. Le ven. 15 mars 2019 à 19:00, Alex Herbert <alex.d.herb...@gmail.com> a écrit : > > > > > 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.
Yes. I recall this was mandated to allow testing with DieHarder. > > 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. I don't remember why I wrote that, but as you pointed outit now looks like a plain bug. > 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. Got it. Thanks. Gilles > > 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
