rand: Add next_f64/f32 to Rng.

[huonw]

Some random number generates output floating point numbers directly, so
by providing these methods all the functionality in librand is available
with high-performance for these things.

An example of such an is dSFMT (Double precision SIMD-oriented Fast
Mersenne Twister).

The choice to use the open interval [0, 1) has backing elsewhere,
e.g. GSL (GNU Scientific Library) uses this range, and dSFMT supports
generating this natively (I believe the most natural range for that
library is [1, 2), but that is not totally sensible from a user
perspective, and would trip people up).

Fixes rust-lang/rfcs#425.

[ghost]

I'm not knowledgeable about the topic but does this in any way skew random streams that are otherwise evenly distributed?

[huonw]

It does; there is precisely one value that doubles in frequency: 0.25. Let eps be the floating point precision, e.g. 2^-53 for f64 and x = eps/4 be the value added here, then 0.25 = 0.25 + x = 0.25' + x where 0.25' = 0.25 - x is the largest float less than 0.25.

However, this is doubling from 1 in 2^-53 to 1 in 2^-52 (or 24 → 23 for f32) which is rather small. It's exceedingly unlikely that a consumer of f64's will see 0.25 even once (but rather less unlikely for f32's).

I think I investigated this before for the original implementation to see what was done elsewhere, but I have forgot it, and did not record my findings.

(Note that this line isn't actually changing the functionality.)

[huonw]

dSFMT operates on numbers between 1.0 and 2.0, just ors with 1 in the smallest bit and then subtracts 1.0 to lie in the open interval (0.0, 1.0) (e.g. 0 becomes 2^-53). That behaviour halves the output space, but it does not lead to a bias.

GSL does rejection sampling (calling the RNG until 0 is not encountered, which is rather likely). I guess we should consider doing that.

[ghost]

Thanks @huonw!

[alexcrichton]

From an API-point-of-view it is somewhat unfortunate to see gen<T: Rand> as well as things like next_u32 and next_u64 (plus the float versions now). It would be kinda cool if Rng implementors could override gen<u32> or gen<u64>, but that's very pie in the sky :)