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