[swift-evolution] [Draft][Proposal] Formalized Ordering

[Dave Abrahams]

on Sat Jul 23 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

> On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon <scanon at apple.com> wrote:
>
>> > The point of this design is that `===` means identity and that `.same `
>> > also means identity.
>> >
>> > Since this is new territory I suppose we get to decide what identity
>> > means for floating point.  Should +0 and -0 have the same identity or
>> > not?  I’ll leave the answer to folks more knowledgable about numerics
>> > than I.
>>
>> Boy, I take my wife out for a movie and come back to 50 new messages on SE.
>>
>> I need to read the entire thread more carefully, but off the top of my
>> head, I think that `-0 === +0` is False.  If we’re going to have an
>> `isSame` / `isIdentical` / whatever it's called, I would expect it to imply
>> substitutability.  Although -0 == +0, they are not equivalent when
>> substituted:
>>
>> - 1/(-0) != 1/0
>> - Float(-0).sign != Float(+0).sign
>> - etc
>>
>> This probably then implies that `<=>` is not `.same` either.  I’ll read
>> the rest of this and respond more completely tomorrow.
>>
>
> Eagerly await your evaluation of the discussion. In the meantime:
>
> I think Dave's view that `===` defines identity in terms of "essential"
> qualities implies that two identical values can be
> different/non-substitutable in "inessential" qualities. For generic
> purposes, the sign of zero could be one such inessential quality.

Yes, and I think our view of how people work with numbers in swift (and
their protocol conformances) reflect this approach.  

http://article.gmane.org/gmane.comp.lang.swift.evolution/16321

My sense is that we want to choose the default notions of identity and
ordering so as to support the way people think about these numeric
types, inexact though it may be.  Therefore, finding 0.0 in a sequence
of floats should succeed when the sequence contains -0.0, and a stable
sort on floating point keys should preserve the relative order of all
elements having +0.0 and -0.0 keys.  

People that want to work with inessential qualities such as the sign of
zero can always pass Float.totalOrdering (or whatever) to their
closure-accepting algorithms.

[In order to support the user model, we still need to fix the semantics
of the default identity and ordering operations so that things like
sorting and searching work, which is why == and < won't cut it for these
purposes]

> On the other hand, the stdlib stride algorithm is going to be borked if -0
> < +0. Of course, as we already started to do there, we could specialize for
> floating point and then adjust accordingly. However, it seems to me that
> every generic algorithm that performs comparisons and can take floating
> point arguments would have to be specialized to account for floating point
> -0 != +0 (`index(of:)` being the previous example). This appears to defeat
> the aim of trying to accommodate FP at all in this revised design for
> Comparables.

Yes, that would be a disaster, generically speaking.

> The argument for `-0 === +0` is that -0 and +0 should be equivalent when
> substituted for every comparison operation. For FP operations, you'd
> continue to test (as you have to test now) `a == b && a.sign == b.sign` if
> you cared about the sign of zero. For non-FP arithmetic operations, hmm,
> not sure how to square that circle.

I followed all of this... except, what are you getting at with that last
sentence?

--
Dave