add cmp() to f32 and f64, with tests

[indirect]

Sometimes, it becomes necessary to find out if one of your floats is
bigger or smaller than another one of your floats. In my case, I had a
list of floats I had calculated, and I wanted to sort them biggest to
smallest. Using sort_by() requires cmp, so I initially wrote my own
fcmp, and then realized that was silly and it should just be built in.

[thestinger]

It's not a correct implementation of TotalEq. It requires these invariants:

• a != b returns the same value as !(a == b)
• a == a is true
• a == b implies b == a
• a == b && b == c implies a == c

The first two requirements are not true for floating point types using this implementation. It's separate from Eq because Eq is implemented for floating point types via the hardware comparison operation. It's also not a correct implementation of TotalOrd for similar reasons.

What should cmp for two NaN values return? At the moment it's saying they are equal. However, the TotalEq implementation is saying they are not equal. It's also treating -0.0 and 0.0 as equal but they are not equivalent, so it's breaking some basic assumptions about equality/ordering.

[indirect]

So the official stance of Rust is that it's not possible to sort floats?

Is this pull so unfixable that it really deserved to be closed without comment beyond "it's wrong sometimes"?

[lilyball]

@indirect I believe that, by definition, IEEE floating-point values cannot possibly implement TotalEq and TotalOrd. The requirements of those traits are incompatible with NaN.

[thestinger]

@indirect: The TotalEq and TotalOrd traits exist because floating point types implement Eq and Ord. It may make sense to do things differently, but incorrect implementations of TotalEq and TotalOrd are not the right solution. They would be no different than Eq and Ord...

[indirect]

I gathered "not the right solution". That's a very concise restatement leading to my previous question, which is still unanswered. What is the right way?

I'm somewhat incredulous because, as far as I can tell, your answer seems to be "never want to sort floats".

On Tue, Feb 11, 2014 at 2:54 PM, Daniel Micay notifications@github.com
wrote:

@indirect: The TotalEq and TotalOrd traits exist because floating point types implement Eq and Ord. It may make sense to do things differently, but incorrect implementations of TotalEq and TotalOrd are not the right solution.

Reply to this email directly or view it on GitHub:
#12193 (comment)

[thestinger]

I think we should have Eq and Ord represent a total ordering, and perhaps implement the floating point total ordering predicate to implement them for floating point types. The traditional ordering can be made available through other methods, possibly via a Float trait.

[thestinger]

#10320