[swift-evolution] [pitch] Comparison Reform

Dave Abrahams dabrahams at apple.com
Sun Apr 23 06:43:47 CDT 2017

on Sat Apr 22 2017, David Waite <david-AT-alkaline-solutions.com> wrote:

>> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> I don’t think that this proposal is acceptable as written.  I think
>> it is really bad that abstracting a concrete algorithm would change
>> its behavior so substantially.  I don’t care about SNaNs, but I do
>> care about the difference between +0/-1 and secondarily that of NaN
>> handling.  It seems really bad that generalizing something like:
>> func doThing(a : Double, b : Double) -> Bool {
>>   ….
>>   return a != b
>> }
>> to:
>> func doThing<T : FloatingPoint> (a : T, b : T) -> Bool {
>>   ….
>>   return a != b
>> }
>> would change behavior (e.g. when a is -0.0 and b is +0.0).   Likewise, "T : Equatable”.
> Did I misunderstand the proposal? If T : FloatingPoint is not included
> in level 1 comparisons, then you cannot have classes of generic
> floating point algorithms.

You did not.

> I personally feel sets/dictionaries of FloatingPoint keys to be more
> brittle than other types merely on the basis of the FloatingPoint
> numbers being an approximation within the real space. Different ways
> to compute a number may have different rounding errors, which makes
> container lookup less useful.

I agree that is an important mitigating factor.  

Don't forget, though, that some FP numbers don't come from computation,
but from direct user input.  Because that's the only official
representation we have for Real numbers, they will get used all over.
(Sometimes I think there should be a separate Real type that ordinary
users work with, leaving all the fun of FP to hard-core numericists).

> In my opinion this is much more about making generic algorithms
> relying on equatable/hashable/comparable able to make safe
> assumptions.

That's a great insight.  I'd add, “be clearly documented, and produce
understandable results.”  IOW, it's not just about serving the generic
algorithm author, but about giving users a model they can work with.


More information about the swift-evolution mailing list