Explicit and deliberate comparison of IEEE floating point numbers.
Comparing floating point values for equality is really hard. To get it right requires careful thought and iteration based on the needs of each specific algorithm's inputs and error margins. This API provides a toolbox of components to make your options clear and your choices explicit to future maintainers.
Given how widely algorithmic requirements can vary, float_eq explores the
idea that there are no generally sensible default margins for comparisons.
This is in contrast to the approach taken by many existing crates, which often
provide default epsilon values in checks or implicitly favour particular
algorithms. The author's hope is that by exposing the inherent complexity in
a uniform way, programmers will find it easier to develop an intuition for how
to write effective comparisons. The trade-off is that each individual
comparison requires more iteration time and thought.
And yes, this is yet another crate built on the principles described in that Random ASCII [floating point comparison] article, which is highly recommended background reading 🙂.
This crate provides boolean comparison operations:
```rust assert!(floateq!(1000.0f32, 1000.0002, ulps <= 4));
// f32::EPSILON.sqrt() const ROUNDINGERROR: f32 = 0.00034526698; assert!(floatne!(4.0f32, 4.1, rel <= ROUNDINGERROR)); ```
And asserts:
```rust // 1.5 * 2f32.powi(-12), as per SSE intrinsics documentation const RECIPRELEPSILON: f32 = 0.00036621094; let recip = 0.1f32.recip(); assertfloateq!(recip, 10.0, rel <= RECIPRELEPSILON);
assertfloatne!(0.0_f32, 0.0001, abs <= 0.00005, ulps <= 4); ```
See the [API documentation] for a long form introduction to the different kinds
of checks, their uses and limitations. Comparison of new types is supported by
implementing the FloatEq and FloatDiff traits.
no_std support.There are a number of existing crates that implement these kinds of comparisons
if you're looking for a more mature solution or simply a different approach.
The [approx], [float-cmp] and [almost] crates all provide a similar style
of general comparison operations, whereas [assert_float_eq] focuses
specifically on assertions. In contrast, [efloat] comes at the problem from a
different angle, instead tracking the error bounds of values as operations are
applied.
Investigate the safety guarantees of the ulps check. Currently, it doesn't act like the default floating point checks when it comes to NaNs and other special values.
More exhaustive testing. Tests currently cover all basic functionality, but there are lots of edge cases that aren't being tested yet.
Benchmark performance, especially the implications of chaining multiple tests.
Constructive feedback, suggestions and contributions welcomed, please [open an issue].