Crate evaluation for 2017-07-25: rand

41

So there is a native floating-point PRNG: dSFMT. In the slides attached there are sometimes quite large speed-ups over conversion from integers, depending on the CPU used.

This suggests there may be benefit in keeping next_f64 / next_f32 in Rng, however there are two drawbacks:

  1. A pure-FP generator is going to have to write inefficient conversions for next_u32 etc.
  2. no_std users want to keep all FP operations out of Rng

I would be tempted to remove next_f64 and _f32 anyway, since I imagine there are very few users who would really care about the performance benefit of native FP generators.