commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gillese...@gmail.com>
Subject Re: [Rng] New XoShiRo generators
Date Sat, 16 Mar 2019 02:54:02 GMT
Hi.

Le ven. 15 mars 2019 à 19:00, Alex Herbert <alex.d.herbert@gmail.com> a écrit :
>
>
>
> > 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.

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message