[swift-evolution] [pitch] Comparison Reform

[Jonathan Hull]

> On Apr 25, 2017, at 7:34 AM, Stephen Canon <scanon at apple.com> wrote:
> 
> 
>> On Apr 24, 2017, at 10:06 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> As I am thinking about it more, this means that for == and <
>> 
>> NaN == NaN
>> -0 == +0
>> +Inf < NaN
>> 
>> Since this would break from IEEE, I think we should also consider taking the opportunity to make == and < work with a default tolerance.  That is, 'a == b' would check that (a - b) < epsilon for some reasonable choice of epsilon that works for common usage.  I know this would make the hash function harder to write, but I think it is worthwhile.
> 
> It’s possible to tinker with IEEE comparisons and maybe improve them or at least work to make them compatible in some way with the expectations of Comparable. Making them have a tolerance by default is out of the question, however: as soon as you add a tolerance, you give up transitivity of equality, which is a much, much worse violation of the axioms than anything inflicted by the presence of NaN in the IEEE 754 model.
> 
> – Steve

Ah, yes, you are correct. Thank you, I now understand why no one bakes in a tolerance…

A couple of quick questions:

How much flexibility do we have around how we treat NaN (especially if there is a way to specify complete 754 compliance using alternate syntax)?  For example NaN != NaN is used in some C algorithms to identify Nan, but we also have isNan() now.  How important is that assumption to the whole system?

What is the importance of signaling Nan in the context of Swift (besides interoperability with computer systems from the 1980’s)?


It strikes me that (quiet) NaN is basically a legacy form of optional (although we treat nil == nil).  It is a shame we can’t merge the two concepts somehow.

My idea of making (quiet) NaN the binary representation of nil for ‘Double?’ and then migrating Double to Double? (which would then give us a non-optional Double where we guaranteed a lack of NaN) was shot down immediately, but I wasn’t really given a reason why.  What I liked about that is that it would be easy to define comparable on non-optional Double, and ‘Double?' would have the same propagation properties as NaN. It would also work well with legacy C and ObjC code (just using Double? instead of Double via an overlay).

I am just wondering if there is a different way of looking at this problem that we have overlooked...

Thanks,
Jon