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

[Xiaodi Wu]

On Fri, Jul 22, 2016 at 6:13 PM, Stephen Canon <scanon at apple.com> wrote:

> 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> wrote:
>
> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution <
> 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.
>

Not just porting of existing code: since no modern language has changed the
meaning of `==` and `<`, it will not even occur to someone coming from
another language that this is something for which they will need to develop
an awareness while writing new code in Swift. The possibility of changing
these operators in subtle ways that break correctness of
already-implemented algorithms makes my hair stand on end. (I could not
ensure my Swift code will be correct past the current Swift 3 betas, for
example, short of ceasing to use all standard operators for floating point.)

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/62b39ad2/attachment.html>