Change the Rand trait for bool

[bhickey]

To generate a bool, generate a 32-bit value and test the sign.

Some common pseudo-random number generators exhibit an uneven quality distribution across their bits. Linear congruential generators return odd and even numbers in an alternating fashion. The low order bit of Xoroshiro128+ behaves like a linear feedback shift register. By testing the sign, we can instead rely on the high ordered bit of an emission, which will generally be of higher quality.

[alexcrichton]

Isn't this still just testing one bit of the underlying RNG? Instead of the least significant bit it's just testing the most significant bit? Do RNGs tend to have uniform bit distributions by that point?

[bluss]

Does xoroshiro128+ really have a problem? I thought the statistical tests it brags about would cover that http://xoroshiro.di.unimi.it/

[bhickey]

@alexcrichton, M.E. O'Neill observed that the behavior of the high bit for LCGs follow a better distribution than the low bits. This forms the kernel of PCG. For several classes of fast RNGs (ex. MCG, LCG, Xorshift), this appears to hold true. It's easy, if not time consuming, to run BigCrush for each bit for a generator (i.e. grab the nth bit of a rng output 32 times).

As an alternative to using the sign bit, we could take the parity.

@bluss, from the author comments on Xoroshiro128+:

Beside passing BigCrush, this generator passes the PractRand test suite
up to (and included) 16TB, with the exception of binary rank tests,
which fail due to the lowest bit being an LFSR; all other bits pass all
tests. We suggest to use a sign test to extract a random Boolean value.

[vks]

I think this also applies to next_u32, it should use the high bits rather than the low bits.

[dhardy]

The next_u32 impl is up to the RNG; in the refactor we decided to recommend little-endian order (i.e. low bits) but allow RNGs to do otherwise (the Isaac64 generator now uses both parts if next_u32 is called twice).

[vks]

the Isaac64 generator now uses both parts if next_u32 is called twice

Does this really have better performance than just throwing away one part?

[burdges]

I'd expect two adjacent next_u32 might be inlined together occasionally, no?

[dhardy]

Does this really have better performance than just throwing away one part?

Yes: dhardy#45

[pitdicker]

This was covered in dhardy#68. Sorry for doing double work, I did not look at the open PR's...

For small non-cryptographic RNG's it is natural for the most significant bits to be of higher quality than the least-significant ones, because addition and multiplication always only affect the bits to the left.