The from_bits method has been added to nightly but requires the float_bits_conv feature flag.

Hi there! Version 0.2.6 contains a SemVer backwards incompatible change and should have been made 0.3. The problem is the addition of a public item (method abs()) to a trait (Ieee754). In my crate accurate I do not implement the Ieee754 trait as such, but I have it in scope together with the Float trait from num-traits which also has a method abs(). x.abs() where x: T and T: Float + Ieee754 used to be unambiguous, but with ieee754 0.2.6 it is not. I can work around this by using Float::abs(x). Just wanted to let you know.

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)

x.upto(y) is (at least by me) used a lot for exhaustive testing of floating point algorithms. This sort of task is often embarassingly parallel, and the iteration should break-up-able in O(1) time (and fairly, simply, I think).

I think this should be a conditional feature, though, and not on by default, since I imagine it breaks no-std.

I think that the library doesn't handle subnormal ULPs correctly--here's the JVM implementation, which may be worth imitating on the subnormal case: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/misc/FpUtils.java#1102

Looking at the code, it looks like it is supposed to handle that case, but somehow it is not working. Calling .next() on -0.0 yields NaN.

The current Iter<T> stores two Ts for the start and end, and then requires jumping back and forth between the raw bits and the floating-point, including doing unnecessary computation/checks by using the public next API, especially with the fix for #1. This can probably be significantly optimized by either storing the raw bits and only converting to a float as the last step of Iter::next, or at least splitting next into a public and a private API.

https://travis-ci.org/bakervm/bakervm/jobs/226211621

This crate should really appear close to the top of search results for "float" in crates.io, without having to remember the exact number of the IEEE standard :)