I've just published version 0.6.0 of float_eq, for comparing floating point values.
This release adds support for arrays of any size now that the required support for const generics has reached stable.
I have reworked the documentation to follow the style of the Diátaxis Framework, which should make it clearer and easier to browse/search. In particular I have added an introductory guide to explain exactly why comparing floats can be so difficult and how float_eq may help.
The implementation is functionally the same as the previous release (0.5.0), but many of the extension traits, types and methods have been renamed from epsilon, max_diff and such to refer to tolerance/tol, which is the mathematical term of art. I wouldn't normally make this kind of a change to an API, but it is still a 0.x version and this should significantly reduce ambiguity and lead to less confusion in future. The surface API has not changed, so this will only affect you if you have derived the traits or implemented them over custom types, in which case you will need to perform a pass over them to change their names.
How does float_eq differ from approx or float-cmp?
Commonly, floating point comparison libraries like approx and float-cmp will try to shield their users from error analysis by providing default tolerances in their comparisons. This is mainly where float_eq differs - it takes the stance that there are no sensible defaults because any given choice of tolerance will depend on the specific algorithm, implementation and inputs. It is built in a way that encourages implementers to be explicit with this analysis in their code and communicate that to future readers and maintainers.
More pragmatically, all of the crates provide similar functionality for comparing floating point values so I recommend trying them out and seeing what best fits your needs.