Consider simplifying the API and using free functions more

[huonw]

Much of the API can probably be implemented in terms of a much more minimal Ieee754 trait, that basically just describes the bit layout. Everything could then be implemented as (generic) free functions, like ieee754::ulp(1.0), or ieee754::iter(0.0..1.0)

[tspiteri]

If the API is simplified, I think that most (three from four) associated types can be removed:

• Ieee754::Exponent and Ieee754::RawExponent can be replaced by i32 and u32, similar to how the standard library's methods that count the number of bits return u32. This assumes the trait will not be used for floating-point number wider than 2624 bits. (A 2624-bit IEEE754 number has a precision of 2592, that is 1 sign bit, 32 exponent bits and 2591 mantissa bits, with the raw exponent in the range 0 ≤ x ≤ 2³² − 1, and the true exponent in the range −2³¹ + 2 ≤ x ≤ 2³¹ − 1 since the true exponent is only meaningful for normal numbers. If that is too tight, a 2208-bit number needs only 31 bits for the exponent.) I don't think this trait is aimed at such large numbers.
• Ieee754::Significand can be replaced by Ieee754::Bits; is there a point in having a narrower mantissa? The only practical case I can think of is not strictly IEEE754: bfloat16 has a precision of only 8 while the number is 16 bits wide, but I don't think having a narrower significand in this case is worth the extra type.