> On Jul 22, 2016, at 6:55 PM, Matthew Johnson <matt...@anandabits.com> wrote:
>
>> On Jul 22, 2016, at 5:50 PM, Stephen Canon <sca...@apple.com
>> <mailto:sca...@apple.com>> wrote:
>>
>>> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
