New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why OrderedFloat is not IEEE conformant? #36
Comments
So according to what I could find about the definition of total order provided by IEEE 754, part of it would require that negative zero and positive zero compare differently from the default implementation. In other words, This looks like a big problem because Rust's documentation for
If IEEE-conformant total order is implemented using The only way I can think of to avoid this would be to have a separate trait specifically for floating-point total order. (Btw, this is all based on what I could find from the section I linked above. If I misunderstood something or got something wrong, feel free to correct me.) |
If we would implement This is definition of total order from the standard:
|
@kryptan because people (myself included) still expect these wrappers to behave like a number. The aim is to be as close as possible to how ordering works for the native float types, whilst still upholding the guarantees of Ord. If negative zero compared differently to positive zero it would be useless for me and many other people. It may make sense to have another type that implements the IEEE-defined ordering, but I suspect it will see less usage... |
For
OrderedFloat
:IEEE standard requires different NaNs to be not equal, positive NaN to be greater than +∞ and negative NaN to be less than -∞. It also requires -0 to be less than +0. Why non-conformant behavior was chosen? Wouldn't it make more sense to implement total order as defined in standard instead?
This Stack Overflow answer is presumably providing a fast way to implement IEEE total order comparison.
The text was updated successfully, but these errors were encountered: