#20 rarns64::raw64() bug

[Lucas Rey]

I am not certain this is a bug, but it feels like it..
in rarns16::raw16, Uint16 is used and the function rotate16 is used.
in rarns32::raw32, Uint32 is used and the function rotate32 is used.
however in rans54::raw64, Uint64 is used and both functions rotate64 AND rotate32 are used.

I have no point of comparison for this RNG so I can't assert this is a bug, but it feels to me that rotate32 should NOT be used with Uint64 since it does not perform a strict "rotation" in that case.

[Lucas Rey]

*rans64::raw64

It is a bug. I'd say it will be fixed in the next release, but it's more accurate to say that all rarns code has been rewritten for the next release.

New version of rarns algorithm looks like:

    enum {
        S1 = 3,
        S2 = 8,
        S3 = 31,
        OUTROT = 32
    };
    Uint64 rv = rotate64(xs1 + xs3, OUTROT);
    xs1 ^= xs2;
    xs2 ^= xs3;
    xs3 ^= xs1;
    xs2 = rotate64(xs2, S2);
    xs3 = rotate64(xs3, S3);
    xs1 ^= xs1 >> S1;
    return rv + xs3;

Though the seeding functions and fast-forwarding/rewinding are still being worked on. Shifts are 2/11/26/16 at 32 bit, and 1/3/10/8 at 16 bit. Those are all maximum period xor-based-generators with outputs hashed well enough to pass tests.

[Lucas Rey]

found another potential issue, I'll just write it here since there is a re-write:

in void PractRand::RNGs::Raw::efiix8x48::seed(Uint64 s1, Uint64 s2, Uint64 s3, Uint64 s4)
I would suggest replacing:

iteration_table[0] = 0;
indirection_table[0] = 0;

in lines 243 and 244 with:

    for (unsigned long y = 0; y < ITERATION_SIZE; y++) {
    iteration_table[y] = 0;
}
for (unsigned long y = 0; y < INDIRECTION_SIZE; y++) {
    indirection_table[y] = 0;
}

this is because in the algo afterwards all the values are NOT initialised, therefore leaving the door open for a (truly) random initialised state.