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

[Dave Abrahams]

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

> That last sentence: division is defined in Arithmetic (IIUC--I'm not in
> front of a traditional computer ATM). 

Yes.

> I would expect, for any arithmetic type T, that the following would
> return true:
>
> let a, b, c: T
> if a == b {
> return c/a == c/b
> }
>
> This would not hold for all a and b if -0 === +0.

That would be nice, wouldn't it?  But there are lots of expected
arithmetic laws that floating point won't obey.

>
>
> On Sat, Jul 23, 2016 at 13:41 Dave Abrahams <dabrahams at apple.com> wrote:
>
>>
>> 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
>>