<div dir="ltr">On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams <span dir="ltr"><<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
on Tue Apr 18 2017, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
<br>
> On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>><br>
>> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution <<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution <<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution <<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> For example, I expect `XCTAssertEqual<T : FloatingPoint>(_:_:)` to be<br>
>> vended as part of XCTest, in order to make sure that `XCTAssertEqual(<wbr>resultOfComputation,<br>
>> Double.nan)` always fails.<br>
>><br>
>><br>
>> Unit tests strike me as an example of where you really *don't* want level<br>
>> 1 comparison semantics. If I'm testing the output of an FP operation, I<br>
>> want to be able to test that it produces nan when I expect it to, or that<br>
>> it produces the right zero.<br>
>><br>
>><br>
>> I find it very concerning that == will have different results based on<br>
>> concrete vs generic type parameters. This can only lead to significant<br>
>> confusion down the road. I’m highly concerned about situations where<br>
>> taking a concrete algorithm and generalizing it (with generics) will change<br>
>> its behavior.<br>
>><br>
>><br>
>> It is already the case that you can start with a concrete algorithm,<br>
>> generalize it, and get confusing results – just with a different starting<br>
>> point. If you start with a concrete algorithm on Int, then generalize it to<br>
>> all Equatable types, then your algorithm will have unexpected behavior for<br>
>> floats, because these standard library types fail to follow the rules<br>
>> explicitly laid out for conforming to Equatable.<br>
>><br>
>> This is bad. Developers need to be able to rely on those rules. The<br>
>> standard library certainly does:<br>
>><br>
>> let a: [Double] = [(0/0)]<br>
>> var b = a<br>
>><br>
>> // true, because fast path buffer pointer comparison:<br>
>> a == b<br>
>><br>
>> b.reserveCapacity(10) // force a reallocation<br>
>><br>
>> // now false, because memberwise comparison and nan != nan,<br>
>> // violating the reflexivity requirement of Equatable:<br>
>> a == b<br>
>><br>
>><br>
>> Maybe we could go through and special-case all the places in the standard<br>
>> library that rely on this, accounting for the floating point behavior<br>
>> (possibly reducing performance as a result). But we shouldn't expect users<br>
>> to.<br>
>><br>
><br>
> I was not thinking about the issue illustrated above, but this is<br>
> definitely problematic to me.<br>
><br>
> To be clear, this proposal promises that `[0 / 0 as Double]` will be made<br>
> to compare unequal with itself, yes?<br>
<br>
</div></div>Nope.<br>
<br>
As you know, equality of arrays is implemented generically and based on<br>
the equatable conformance of their elements. Therefore, two arrays of<br>
equatable elements are equal iff the conforming implementation of<br>
Equatable's == is true for all elements.<br>
<span class="gmail-"><br>
> It is very clear that here we are working with a concrete FP type and<br>
> not in a generic context, and thus all IEEE FP behavior should apply.<br>
<br>
</span>I suppose that's one interpretation, but it's not the right one.<br>
<br>
If this were C++, it would be different, because of the way template<br>
instantiation works: in a generic context like the == of Array, the<br>
compiler would look up the syntactically-available == for the elements<br>
and use that. But Swift is not like that; static lookup is done at the<br>
point where Array's == is compiled, and it only finds the == that's<br>
supplied by the Element's Equatable conformance.<br>
<br>
This may sound like an argument based on implementation details of the<br>
language, and to some extent it is. But that is also the fundamental<br>
nature of the Swift language (and one for which we get many benefits),<br>
and it is hopeless to paper over it. For example, I can claim that all<br>
doubles are equal to one another:<br>
<br>
9> func == (lhs: Double, rhs: Double) -> Bool { return true }<br>
10> 4.0 == 1.0<br>
$R2: Bool = true<br>
11> [4.0] == [1.0] // so the arrays should be equal too!<br>
$R3: Bool = false<br>
<br>
Another way to look at this is that Array is not a numeric vector, and<br>
won't be one no matter what you do ([1.0] + [2.0] => [1.0, 2.0]). So it<br>
would be wrong for you to expect it to reflect the numeric properties of<br>
its elements.<br>
<span class="gmail-"><br>
>> This is a bump in the rug – push it down in one place, it pops up in<br>
>> another. I feel like this proposal at least moves the bump to where fewer<br>
>> people will trip over it. I think it highly likely that the intersection of<br>
>> developers who understand enough about floating point to write truly<br>
>> correct concrete code, but won’t know about or discover the documented<br>
>> difference in generic code, is far smaller than the set of people who hit<br>
>> problems with the existing behavior.<br>
>><br>
><br>
> So, to extend this analogy, I'd rather say that the bump is not in the rug<br>
> [Comparable] but rather in a section of the floor [FP NaN]. The rug might<br>
> overlie the bump, but the bump will always be there and people will find it<br>
> as they walk even if they don't immediately see it.<br>
<br>
</span>Correct.<br>
<span class="gmail-"><br>
> If we don't want people to trip over the bump while walking on the<br>
> rug, one very good alternative, IMHO, is to shape the rug so that it<br>
> doesn't cover the bump.<br>
<br>
</span>At what cost?<br>
<br>
More specifically: why is it the right behavior, for our audience, to<br>
trap when Equatable comparison happens to encounter NaN? Will this not<br>
simply "crash" programs in the field that otherwise would have "just<br>
worked?"<br>
<span class="gmail-"><br>
> My purpose in exploring an alternative design is to see if it would be<br>
> feasible for non-FP-aware comparison operators to refuse to compare NaN,<br>
> rather than giving different answers depending on context.<br>
<br>
</span>So... to be clear, this is still different behavior based on context.<br>
Is this not just as confusing a result?<br>
<br>
let nan = 0.0 / 0.0<br>
print(nan == nan) // false<br>
print([nan] == [nan]) // trap<br></blockquote><div><br></div><div>No, in my alternative proposal:</div><div><br></div><div>```</div><div> let nan = 0.0 / 0.0<br> print(nan == nan) // trap<br> print([nan] == [nan]) // trap<br></div><div> print(nan &== nan) // false</div><div> print([nan] &== [nan]) // false</div><div>```</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> I now strongly believe that this may make for a design simultaneously<br>
> _less_ complex *and* _more_ comprehensive (as measured by the<br>
> flatness-of-rug metric).<br>
<br>
</span>I'm certainly willing to discuss it, but so far it doesn't seem like<br>
you've been willing to answer the central questions above.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
-Dave<br>
</font></span></blockquote></div><br></div></div>