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

[Xiaodi Wu]

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160723/2b85f196/attachment.html>