> On Nov 1, 2017, at 9:16 AM, Ben Cohen via swift-dev <swift-dev@swift.org>
> wrote:
>> On Oct 31, 2017, at 10:11 PM, Chris Lattner via swift-dev
>> <swift-dev@swift.org> wrote:
>> On Oct 31, 2017, at 9:07 AM, Stephen Canon via swift-dev
>> <swift-dev@swift.org> wrote:
>>> [Replying to the thread as a whole]
>>>
>>> There have been a bunch of suggestions for variants of `==` that either
>>> trap on NaN or return `Bool?`. I think that these suggestions result from
>>> people getting tunnel-vision on the idea of “make FloatingPoint equality
>>> satisfy desired axioms of Equatable / Comparable”. This is misguided. Our
>>> goal is (should be) to make a language usable by developers; satisfying
>>> axioms is only useful in as much as they serve that goal.
>>>
>>> Trapping or returning `Bool?` does not make it easier to write correct
>>> concrete code, and it does not enable writing generic algorithms that
>>> operate on Comparable or Equatable. Those are the problems to be solved.
>>
>> +100. Swift isn’t the first language to face the problems of floating
>> point, nor is it the first to try to shoehorn it into a framework like
>> Equatable.
>
> Java and C# do not have this problem with their generic algorithms (albeit
> possibly because of limitations in their languages that Swift doesn’t have).
> Swift is setting itself up as a major language with confusing and
> unjustifiable behavior by comparison. That some other languages are also bad
> at this doesn’t seem relevant.
The common (and correct!) wisdom in _any_ programming language that uses IEEE
floating point is that checking equality of two floating point values is almost
always a terrible idea. Usually what you want in any real world code is to
check for a difference less than some epsilon value, which depends upon
context. There are just too many issues with values that aren’t exactly
representable, rounding errors during computations, et cetera, for perfectly
normal floats even if you completely left aside equality rules for NaN.
I completely understand the desire in this thread to make floating point really
satisfy the axioms of Equatable, but the fact is, even if you did, using a
generic algorithm that depends upon equatability with floating point types is
almost always just a programming error waiting to happen. It’s implicit in the
representation and use of floating point values themselves, no matter what
particular implementation you decide on for == or &==.
If you really want to make the language better for developers, provide and
emphasize fixed point or infinite precision or rational types for doing various
things instead, and encourage them to shun floats as much as possible. If you
really need to change anything about the standard library of Swift, my
preferred solution would be to continue to provide ==(lhs : Float, rhs: Float)
and != but NOT declare conformance to Equatable at all so that generic
algorithms involving floats would fail to compile.
- Greg
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
