rand: Add next_f64/f32 to Rng. #18534
Conversation
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.
| @@ -124,23 +120,22 @@ macro_rules! float_impls { | |||
| // the precision of f64/f32 at 1.0), so that small | |||
| // numbers are larger than 0, but large numbers | |||
| // aren't pushed to/above 1. | |||
| Open01(((rng.$method_name() >> $ignored_bits) as $ty + 0.25) / SCALE) | |||
| Open01(rng.$method_name() + 0.25 / SCALE) | |||
There was a problem hiding this comment.
I'm not knowledgeable about the topic but does this in any way skew random streams that are otherwise evenly distributed?
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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.
|
From an API-point-of-view it is somewhat unfortunate to see |
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.