[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Mon, Apr 24, 2017 at 11:44 PM, David Waite <david at alkaline-solutions.com>
wrote:

> I still think this is a naming conflict more than anything else.
>
> The first expectation is that equatable and comparable provides strict
> equality and strict total ordering, and that those are exposed via
> operators. The other expectation is that floating point abides by the IEEE
> rules which have neither of these, and are exposed via operators.
>
> Either:
> 1. the operators need to do different things in different contexts
>

Right, this is the proposal that started the thread. A number of people
object to this idea.


> 2. we need different methods/operators to indicate these different concepts
>

Right, I and others have proposed designs for this. A number of people also
object to this idea.


> 3. Equatable and comparable need to be altered to no longer require strict
> equality and strict total ordering (and all generic algorithms based on
> equatable/comparable need to be checked that they still work)
>

If you read the documentation on Comparable, it actually says: "A
conforming type may contain a subset of values which are treated as
exceptional." It goes on to describe floating point semantics. So this is
the status quo.


> 4. floating point numbers need to explicitly not be equatable/comparable
> to prevent their usage in generic algorithms requiring strict behavior.
>

I think we can all agree that not being able to compare arrays of floating
point numbers would be rather limiting.


> 5. We break away from IEEE behavior and provide only strict equality and
> strict total ordering
>
> (I tried to sort these roughly in order of feasibility)
>

Right, 5 is totally a non-starter.

Are there any other options?
>

Your list is pretty exhaustive. Even though I've tried to promote designs
along some of these lines in the past, I can safely say that for myself I
dislike all of these choices.

As to (3), one point to be made is that it is actually possible to make all
generic algorithms work sensibly with the current design of Comparable. You
can make `sort`, for example, behave exactly as Dave and Ben propose using
what we have today. An issue to consider is that a naive implementation of
the additional checks necessary for that result would penalize types that
are currently well-behaved.

There are judicious tweaks to the design of Equatable and/or Comparable
that could help the compiler elide any additional checks when a type is
well-behaved. For example, if `Comparable` had a requirement named
`isExceptional` (for exceptional values), then `sort` could evaluate
`areInIncreasingOrder($0,
$1) || ($1.isExceptional && !$0.isExceptional)` in order to sort NaN
greater than everything else, as desired. A type that has no exceptional
values would implement `var isExceptional: Bool = false`, and the compiler
could elide the additional checks.

(Another issue to think about with (3) is that few people who are writing
their own generic algorithms would be motivated to actually do look into
this issue or know that they should even think about it; it is, after all,
the status quo and we know that generic algorithms *aren't* taking NaN into
account. The issue is that for every "motivation" we build into an
alternative design, it represents a roadblock or a nuisance to someone else
who, for example, just wants their numerics algorithms to work.)


> -DW
>
> > On Apr 24, 2017, at 9:50 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> > on Mon Apr 24 2017, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
> >
> >> On Mon, Apr 24, 2017 at 9:06 PM, Jonathan Hull via swift-evolution <
> >> swift-evolution at swift.org> wrote:
> >>
> >>> As I am thinking about it more, this means that for == and <
> >>>
> >>> NaN == NaN
> >>> -0 == +0
> >>> +Inf < NaN
> >>>
> >>> Since this would break from IEEE,
> >>
> >> Yeah, as Steve mentioned, it's a huge deal to break from IEEE rules.
> >
> > Allow me to put it even more strongly: I consider reinventing how
> > floating point works to be a massive undertaking comparable to
> > supplanting the Unicode standard with something better.  I have no doubt
> > that it could be done by somebody, somewhere, someday, but it would be
> > easy to do something much worse than what IEEE has done, and getting it
> > right would occupy so much of this group's time that we couldn't hope to
> > accomplish anything else, if we even had the expertise—I know I don't!
> > Doing anything in this area that is not firmly rooted in existing
> > standards and practices is not an option I'm willing to pursue.
> >
> > --
> > -Dave
> > _______________________________________________
> > 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/20170425/204bcb39/attachment.html>