<div style="white-space:pre-wrap">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:<br><br>let a, b, c: T<br>if a == b {<br> return c/a == c/b<br>}<br><br>This would not hold for all a and b if -0 === +0.<br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 23, 2016 at 13:41 Dave Abrahams <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Sat Jul 23 2016, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
<br>
> On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote:<br>
><br>
>> > The point of this design is that `===` means identity and that `.same `<br>
>> > also means identity.<br>
>> ><br>
>> > Since this is new territory I suppose we get to decide what identity<br>
>> > means for floating point. Should +0 and -0 have the same identity or<br>
>> > not? I’ll leave the answer to folks more knowledgable about numerics<br>
>> > than I.<br>
>><br>
>> Boy, I take my wife out for a movie and come back to 50 new messages on SE.<br>
>><br>
>> I need to read the entire thread more carefully, but off the top of my<br>
>> head, I think that `-0 === +0` is False. If we’re going to have an<br>
>> `isSame` / `isIdentical` / whatever it's called, I would expect it to imply<br>
>> substitutability. Although -0 == +0, they are not equivalent when<br>
>> substituted:<br>
>><br>
>> - 1/(-0) != 1/0<br>
>> - Float(-0).sign != Float(+0).sign<br>
>> - etc<br>
>><br>
>> This probably then implies that `<=>` is not `.same` either. I’ll read<br>
>> the rest of this and respond more completely tomorrow.<br>
>><br>
><br>
> Eagerly await your evaluation of the discussion. In the meantime:<br>
><br>
> I think Dave's view that `===` defines identity in terms of "essential"<br>
> qualities implies that two identical values can be<br>
> different/non-substitutable in "inessential" qualities. For generic<br>
> purposes, the sign of zero could be one such inessential quality.<br>
<br>
Yes, and I think our view of how people work with numbers in swift (and<br>
their protocol conformances) reflect this approach.<br>
<br>
<a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/16321" rel="noreferrer" target="_blank">http://article.gmane.org/gmane.comp.lang.swift.evolution/16321</a><br>
<br>
My sense is that we want to choose the default notions of identity and<br>
ordering so as to support the way people think about these numeric<br>
types, inexact though it may be. Therefore, finding 0.0 in a sequence<br>
of floats should succeed when the sequence contains -0.0, and a stable<br>
sort on floating point keys should preserve the relative order of all<br>
elements having +0.0 and -0.0 keys.<br>
<br>
People that want to work with inessential qualities such as the sign of<br>
zero can always pass Float.totalOrdering (or whatever) to their<br>
closure-accepting algorithms.<br>
<br>
[In order to support the user model, we still need to fix the semantics<br>
of the default identity and ordering operations so that things like<br>
sorting and searching work, which is why == and < won't cut it for these<br>
purposes]<br>
<br>
> On the other hand, the stdlib stride algorithm is going to be borked if -0<br>
> < +0. Of course, as we already started to do there, we could specialize for<br>
> floating point and then adjust accordingly. However, it seems to me that<br>
> every generic algorithm that performs comparisons and can take floating<br>
> point arguments would have to be specialized to account for floating point<br>
> -0 != +0 (`index(of:)` being the previous example). This appears to defeat<br>
> the aim of trying to accommodate FP at all in this revised design for<br>
> Comparables.<br>
<br>
Yes, that would be a disaster, generically speaking.<br>
<br>
> The argument for `-0 === +0` is that -0 and +0 should be equivalent when<br>
> substituted for every comparison operation. For FP operations, you'd<br>
> continue to test (as you have to test now) `a == b && a.sign == b.sign` if<br>
> you cared about the sign of zero. For non-FP arithmetic operations, hmm,<br>
> not sure how to square that circle.<br>
<br>
I followed all of this... except, what are you getting at with that last<br>
sentence?<br>
<br>
--<br>
Dave<br>
</blockquote></div>