[swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

[Xiaodi Wu]

On Sun, Apr 24, 2016 at 4:51 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > However, I don’t understand how that would help for floating point NaN
> behavior.  Wouldn’t you have to add a fourth member to the enum
> (“unordered’) that all clients would have to handle?  An approach like that
> could make sense.
>
> The point is precisely that there *isn't* an `unordered` case. The
> spaceship operator *must* order all values; that makes it suitable for
> operations like `sort()` and `max()` which assume there is a total order
> over all values they encounter. Meanwhile, the traditional comparison
> operators like `<` and `==` are given flexibility to implement looser
> semantics like those seen in `FloatingPoint`.
>
> On the other hand, just because there is *an* order doesn't mean it'll be
> a *sensible* order. In particular, if `min()` and `max()` are based on an
> ordering which includes NaNs, then in some circumstances at least one of
> them will favor a NaN over a normal value. It might be that the total order
> is not actually a good match for `min()` and `max()`, and they should
> instead use the partial order and ignore unordered elements.
>
> (Of course, that again raises the question of whether it is an element or
> a *pair* of elements which is unordered.)
>
> Perhaps think of it this way: `<=>` is an *ordering* operator; the others
> are *comparison* operators. The difference is that, even if two elements
> cannot be compared, they can still have a consistent order.
>

I think this is an important distinction to make and perhaps argues against
including these changes to Comparable; rather, a separate protocol might be
most appropriate. It's important, for instance, that -0.0 and +0.0 compare
equal, but also that they be ordered differently. Something else to
consider if you insist that all floating point values must be "orderable"
would be how two NaNs are ordered if they have different payloads. As far
as I'm aware, that goes beyond what IEEE 754 has to say about total
ordering of floating point values.


> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160424/d0abae39/attachment.html>