[swift-evolution] [Draft][Proposal] Formalized Ordering

[Stephen Canon]

> On Jul 22, 2016, at 6:55 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> On Jul 22, 2016, at 5:50 PM, Stephen Canon <scanon at apple.com <mailto:scanon at apple.com>> wrote:
>> 
>>> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Sorry if it wasn’t clear.  I’m not suggesting taking that away.  I’m asking whether we have considered defining `==` on floating point types to be the equivalence relation that is proposed for `areSame` and giving the domain specific operation a different name.  
>>> 
>>> Maybe this would break with convention too much, but it would feel much more intuitive (to me at least - although I am admittedly not a numerics expert).
>> 
>> IEEE754 doesn’t specify language bindings, so it *is* allowed to e.g. provide an `isEqualIEEE754` predicate and make `==` do something else.
>> 
>> However, doing so would break with the precedent set by … well, every mainstream programming language of the past 30 years, and make porting existing numeric code an error-prone process for anyone who hadn’t carefully studied this particular aspect of Swift.
> 
> Thanks for chiming in Steve.  I know it isn’t a decision to be taken lightly for sure and breaking the convention may well not be the right idea.  I just wanted to point out that maybe it is possible to consider this without giving up IEEE floating point conformance.
> 
> The fact that `==` isn’t always an equivalence relation makes me sad but maybe the industry is too far down that rabbit hole to consider anything else…

The two *major* issues I foresee with doing this both have to do with implementing / porting existing code.

1. There exists an enormous amount of code (and pseudo-code in publications) that predates the existence of `isnan` in whatever language the code was written with.  These codes explicitly use `x != x` as a test for NaN, and `x == x` as a check for non-NaN.  Users transcribing / porting such code are unlikely to know that they need to change these statements, frequently resulting in bugs that they won’t find unless their test set contains explicitly invalid inputs.

2. I don’t think it would make sense to make `==` an equivalence relation without also making `<` a strict total order.  This would cause bigger problems than `==`, because a lot of numeric code uses something like:

	while (residual > tolerance) {
		// refine
	}

to check for convergence, with a test for NaN following the loop to detect failures; if `<` is made a strict total order, then `NaN` needs to be ordered either before or after finite numbers, and either option will break some loops written in this form.

This sort of code is frequently copied out of books like “Numerical Recipes” with minimal adaptation to whatever the target language is, and even minimal awareness of the precise semantics of the target language.  The great success of IEEE 754 is that this doesn’t *usually* matter; the code works anyway.  Breaking that property seems somewhat antithetical to the safety goals of the language.

There’s also a lesser performance concern (we have 35 years of floating-point hardware designed around the IEEE 754 comparison operators; so doing almost anything else will produce small performance hiccups on most hardware, and large performance issues on some hardware).  This isn’t my major worry, however; we’re trying to design a language for the *next* 35 years (or more), after all, and most of that hardware hasn’t been designed yet.

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/590616b2/attachment.html>