[feature request] total_cmp for num_traits::Float

[felix-clark]

With total_cmp() being stabilized for f32 and f64, could this be included in the floating point trait? It's quite a convenient method for sorting generic floating point types.

[cuviper]

Is there a generic way to write a default implementation? Otherwise, adding a trait method is a breaking change.

[felix-clark]

To my knowledge there is no trivial built-in generic way.

[cuviper]

Then I suppose this will need to be a standalone trait. Something like:

pub trait TotalOrd {
    fn total_cmp(&self, other: &Self) -> Ordering;
}

That could even have impls for integers. In theory, we could have a blanket impl for all T: Ord, but I think coherence would then disallow impls for f32 and f64 in case they add Ord in the future, even though we know they won't.

[andrewjradcliffe]

Incidentally, half provides implementations of total_cmp for both f16 and bf16 which match the signature suggested by @cuviper. Likewise, rug's wrapper around MPFR provides a total_cmp implementation. In other words, it's little more than 5 lines of code for the respective maintainers.

As a separate constraint which could be imposed upon generic types, it would be useful in the rare numerical algorithms which necessitate sorting of floating point numbers (e.g. isotonic regression). NaN in such algorithms will of course produce garbage results, but using total_cmp makes the behavior reasonably transparent to the user -- in contrast to library writers making arbitrary decisions for how NaNs are handled (or not).

The inevitable bikeshedding: TotalOrd feels not quite as clean as one would like. Ord is already total. We could get around this by invoking the source of the ordering, i.e. name the trait IeeeOrd (or IEEEOrd?). While ugly to look at, it has the advantage of clarity.

[cuviper]

We could further distinguish this from PartialOrd/Ord by spelling it out like trait TotalOrder, and include the standard library's documentation that this is "in accordance to the totalOrder predicate as defined in the IEEE 754 (2008 revision) floating point standard." (Or an approximation thereof for 3rd-party types.) We could also keep this in the num_traits::float module and not implement for integers as I had suggested before, so it remains scoped to float-like comparisons.

[andrewjradcliffe]

trait TotalOrder is preferable to IeeeOrd, as the latter is rather generic. Placing it within the num_traits::float module and including "in accordance to the totalOrder predicate..." should be sufficient to disambiguate that the trait is strictly for floating point types.

[cuviper]

@andrewjradcliffe Would you be interested in writing that pull request?

[andrewjradcliffe]

Just saw this today -- I'm not great about checking notifications ._.
Give me a day or so and I'll have the PR ready.