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.

[feature request] total_cmp for num_traits::Float #256

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions