Make distributions generic / impl for f32

[dhardy]

Implement #100: impl for f32 and make distributions generic over the parameter type.

Status: partial type changes only. I haven't started on optimising the algorithms, but have found a few resources of interest.

So far I am liking the way this is going. A few extra type annotations are needed but not many due to the language's preference to resolve floats as f64 (example).

This adds a dependency on the num-traits crate, but only for rand_distr; I think this is acceptable.

Slight annoyance: NumCast::from returns an Option, thus requires .unwrap() (less concise and compiler cannot prove there is no panic). We could instead use std::comvert::From, but this would require an extra bound: N: From<f32>.

[dhardy]

Note that initial attempts to make Binomial generic over its integer type proved less straightforward. Possibly this one will not be made generic (I see less incentive, and even if it were, the probability type would likely stay f64 only).

[dhardy]

@vks would you be able to review?

[vks]

I wonder whether it would make sense to make the parameter an associated type of Distribution, similar to the iterator trait. (In fact, distributions could implement Iterator.)

[vks]

What is the motivation of this? To exercise the type change and optimize later? As of now, it does not seem worth to add this, when dist.sample(&mut rng) as f32 is equivalent.

[dhardy]

Yes, an optimised impl can follow later. Even like this though it helps with some generic coding.

[dhardy]

Remember, the (unparameterised) Standard distribution implements Distribution<u32>, Distribution<f64>, and many more types. To make the type an associated type, we would have to add type parameters to Standard instead. This would be a major breaking change to the main Rand lib, and I think probably less ergonomic to use (would let x: i8 = Standard.sample(&mut rng) work without an internal type parameter?).

[vks]

That is a good point, it would make using unparametrized distributions much more cumbersome, so the current approach is probably best for now.

[vks]

Looks good! I think this is the way we want the interface to look like.