Traits in `std::cmp` and mathematical terminology

[jbe]

@kornel

From a developer perspective: I have arrays of floats, and I need them sorted. I don't care what the proper math says, I have floats, not real numbers. Rust's sound and tight definitions are not helping me when I need to sort floats, and I can't.

The current state simply prevents me from getting my job done. I need to put extra work to do exactly the "bad" thing that Rust is trying to stop me from doing.

I have had the same problem. I always end up with something like:

/// Compare two [`f64`] numbers while treating [NaN](f64::NAN) as greatest.
pub fn cmp_f64_nan_greatest(a: f64, b: f64) -> std::cmp::Ordering {
    a.partial_cmp(&b).unwrap_or_else(|| {
        a.is_nan().cmp(&b.is_nan()).then(std::cmp::Ordering::Equal)
    })
}

And then using that in a closure passed to sort_by.

It's annoying. I agree.

@kornel

I use sort_by(partial_cmp().unwrap_or(Equal)) or wrap floats in a newtype that intentionally incorrectly implements Ord just so that I can get floats sorted.

That I don't do. I'm always worried NaN's could actually appear.

@kornel

Could we have sort() functions that use a trait like Comparable and work on anything that supports < , while accepting and permitting all of the consequences of this comparison being inconsistent?

How about partial_sort, which is happy with PartialOrd? (Maybe I shouldn't have made a new thread, will be more careful next time, as these topics are kinda related.)

P.S.: I just gave an outline of an example in the other thread, as this is related to the original question: "Why sort() need T to be Ord ?"