<div dir="ltr">On Mon, Apr 24, 2017 at 11:44 PM, David Waite <span dir="ltr"><<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.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">I still think this is a naming conflict more than anything else.<br>
<br>
The first expectation is that equatable and comparable provides strict equality and strict total ordering, and that those are exposed via operators. The other expectation is that floating point abides by the IEEE rules which have neither of these, and are exposed via operators.<br>
<br>
Either:<br>
1. the operators need to do different things in different contexts<br></blockquote><div><br></div><div>Right, this is the proposal that started the thread. A number of people object to this idea.</div><div> </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">
2. we need different methods/operators to indicate these different concepts<br></blockquote><div><br></div><div>Right, I and others have proposed designs for this. A number of people also object to this idea.</div><div> </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">
3. Equatable and comparable need to be altered to no longer require strict equality and strict total ordering (and all generic algorithms based on equatable/comparable need to be checked that they still work)<br></blockquote><div><br></div><div>If you read the documentation on Comparable, it actually says: "A conforming type may contain a subset of values which are treated as exceptional." It goes on to describe floating point semantics. So this is the status quo.</div><div> </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">
4. floating point numbers need to explicitly not be equatable/comparable to prevent their usage in generic algorithms requiring strict behavior.<br></blockquote><div><br></div><div>I think we can all agree that not being able to compare arrays of floating point numbers would be rather limiting.</div><div> </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">
5. We break away from IEEE behavior and provide only strict equality and strict total ordering<br>
<br>
(I tried to sort these roughly in order of feasibility)<br></blockquote><div><br></div><div>Right, 5 is totally a non-starter.</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">
Are there any other options?<br></blockquote><div><br></div><div>Your list is pretty exhaustive. Even though I've tried to promote designs along some of these lines in the past, I can safely say that for myself I dislike all of these choices.</div><div><br></div><div>As to (3), one point to be made is that it is actually possible to make all generic algorithms work sensibly with the current design of Comparable. You can make `sort`, for example, behave exactly as Dave and Ben propose using what we have today. An issue to consider is that a naive implementation of the additional checks necessary for that result would penalize types that are currently well-behaved.</div><div><br></div><div>There are judicious tweaks to the design of Equatable and/or Comparable that could help the compiler elide any additional checks when a type is well-behaved. For example, if `Comparable` had a requirement named `isExceptional` (for exceptional values), then `sort` could evaluate `<span style="font-size:12.800000190734863px">areInIncreasingOrder($0, $1) || ($1.isExceptional && </span><span style="font-size:12.800000190734863px">!$0.isExceptional</span><span style="font-size:12.800000190734863px">)` in order to sort NaN greater than everything else, as desired. A type that has no exceptional values would implement `var isExceptional: Bool = false`, and the compiler could elide the additional checks.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div>(Another issue to think about with (3) is that few people who are writing their own generic algorithms would be motivated to actually do look into this issue or know that they should even think about it; it is, after all, the status quo and we know that generic algorithms *aren't* taking NaN into account. The issue is that for every "motivation" we build into an alternative design, it represents a roadblock or a nuisance to someone else who, for example, just wants their numerics algorithms to work.)<span style="font-size:12.800000190734863px"><br></span></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-HOEnZb"><font color="#888888"><br>
-DW<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> On Apr 24, 2017, at 9:50 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
> on Mon Apr 24 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 Mon, Apr 24, 2017 at 9:06 PM, Jonathan Hull via swift-evolution <<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>>> As I am thinking about it more, this means that for == and <<br>
>>><br>
>>> NaN == NaN<br>
>>> -0 == +0<br>
>>> +Inf < NaN<br>
>>><br>
>>> Since this would break from IEEE,<br>
>><br>
>> Yeah, as Steve mentioned, it's a huge deal to break from IEEE rules.<br>
><br>
> Allow me to put it even more strongly: I consider reinventing how<br>
> floating point works to be a massive undertaking comparable to<br>
> supplanting the Unicode standard with something better. I have no doubt<br>
> that it could be done by somebody, somewhere, someday, but it would be<br>
> easy to do something much worse than what IEEE has done, and getting it<br>
> right would occupy so much of this group's time that we couldn't hope to<br>
> accomplish anything else, if we even had the expertise—I know I don't!<br>
> Doing anything in this area that is not firmly rooted in existing<br>
> standards and practices is not an option I'm willing to pursue.<br>
><br>
> --<br>
> -Dave<br>
</div></div><div class="gmail-HOEnZb"><div class="gmail-h5">> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br>
</div></div></blockquote></div><br></div></div>