[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Xiaodi Wu]

On Fri, Oct 20, 2017 at 10:10 Matthew Johnson <matthew at anandabits.com>
wrote:

> On Oct 20, 2017, at 9:36 AM, Xiaodi Wu via swift-dev <swift-dev at swift.org>
> wrote:
>
>
> On Fri, Oct 20, 2017 at 07:21 David Zarzycki <dave at znu.io> wrote:
>
>>
>>
>> On Oct 20, 2017, at 07:51, Xiaodi Wu via swift-dev <swift-dev at swift.org>
>> wrote:
>>
>> On Fri, Oct 20, 2017 at 1:22 AM, Jonathan Hull <jhull at gbis.com> wrote:
>>
>>> +1 for trapping unless using &==.  In the case of ‘Float?’ we could also
>>> map to nil.
>>>
>>> This is probably a more appropriate discussion for evolution though...
>>>
>>>
>>> On Oct 19, 2017, at 9:48 PM, Brent Royal-Gordon via swift-dev <
>>> swift-dev at swift.org> wrote:
>>>
>>> On Oct 19, 2017, at 4:29 PM, Xiaodi Wu via swift-dev <
>>> swift-dev at swift.org> wrote:
>>>
>>> D) Must floating-point IEEE-compliant equivalence be spelled `==`?
>>>
>>> In my view, this is something open for debate. I see no reason why it
>>> cannot be migrated to `&==` if it were felt that `==` *must* be a full
>>> equivalence relation. I believe this is controversial, however.
>>>
>>>
>>> I actually got partway through writing up a pitch on this yesterday, but
>>> my opinion is that NaNs are so exceptional, and so prone to misuse, that we
>>> ought to treat them like integer arithmetic overflows: trap when they're
>>> detected, unless you use an `&` variant operator which indicates you know
>>> what you're doing.
>>>
>>> I strongly suspect that, in practice, most float-manipulating code is
>>> not prepared to handle NaN and will not do anything sensible in its
>>> presence. For example, Apple platforms use floating-point types for
>>> geometry, color components, GPS locations, etc. Very little of this code
>>> will do anything sensible in the presence of a NaN. Arguably, it'd be
>>> better to exclude them through the type system, but I don't think that's a
>>> realistic possibility—we would need to have done that in a more
>>> source-break-friendly era. But that doesn't have to mean we're completely
>>> stuck.
>>>
>>>
>> Built-in floating point operators, as well as libc/libm math functions,
>> are designed to propagate NaN correctly. This is not meant to be a thread
>> about NaN, and we need to be cautious to define the scope of the problem to
>> be solved from the outset. The tendency of having ever-expanding discussion
>> where issues such as method names turn into discussions about the entire
>> standard library go nowhere.
>>
>> The question here is about `==` specifically and how to accommodate
>> partial equivalence relations. For sanity, we start with the premise that
>> NaN will forever be as it is.
>>
>>
>> I support Jonathan’s argument. If Swift wants to trap on NaN to improve
>> self-consistency and simplicity, then the tradeoff might be worth it. The
>> alternative, teaching the Equality protocol about NaNs, feels like “the
>> tail wagging the dog".
>>
>> In short: what IEEE requires of floating-point hardware is separable from
>> IEEE’s opinions about language/library design.
>>
>
> IEEE 754 requires certain behaviors of conforming implementations and is
> meant to allow for portable use of floating point. Swift’s floating point
> facilities are conformant to that standard, and breaking IEEE 754
> conformance has been repeatedly stated to be a non-starter.
>
> The essential idea behind quiet NaN is that it can be used as input in
> operations that take floating point values without raising errors. Since
> breaking IEEE 754 conformance is a non-starter, trapping on NaN is outside
> the realm of available solutions.
>
> It has been pointed out, however, that IEEE does not require a specific
> syntax for floating point equivalence, hence the question of whether it can
> be spelled differently. However, trapping on NaN is emphatically not an
> option.
>
> But I really don’t want to discuss this at all here. The topic of this
> thread is about the semantics of Equatable.
>
>
> On the other hand, changing the spelling of IEEE `==` was option in your
> opening post represented by demand 4 and question  D.
>
> 4) IEEE-compliant floating-point equivalence must be spelled `==` and not
> some alternative such as `&==`.
>
> D) Must floating-point IEEE-compliant equivalence be spelled `==`?
>
>
>
> In my view, this is something open for debate. I see no reason why it
> cannot be migrated to `&==` if it were felt that `==` *must* be a full
> equivalence relation. I believe this is controversial, however.
>
>
> What you call the "proximate issue” goes away if the solution to what you
> call the “distal issue” involves requiring `Equatable` conforming types to
> provide an implementation of `==` that represents a full equivalence
> relation.  It looks to me like many people are suggesting that this is
> exactly what we should do.
>
> I not a numerics expert by any means and am therefore cautious to offer my
> opinion, but rejecting demand 4 appears to be the best option to me.  One
> advantage of this approach in addition to providing a full equivalence
> relation for floating point’s equatable conformance is that it makes it
> clear when an algorithm was written with IEEE semantics in mind or when the
> programmer did not desire or may not be aware of IEEE semantics.
>

I agree.

IMO, the more general issue of partial equivalence relations should be
> orthogonal.  I don’t believe NaN should drive the semantic requirements of
> `Equatable` and I don’t believe IEEE should prevent floating point types
> from providing an Equatable conformance.
>

I think this is reasonable as well.

Perhaps this is a sign of my ignorance of numerics, but that’s the solution
> this seems to make the best tradeoffs.  I am happy to let others decide
> whether `NaN == NaN` should trap or return `true`.
>

Trapping violates the requirements of Equatable and, I think, also IEEE
edicts; NaN == NaN would be the only solution if we dispense with demand 4.

_______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171020/30209363/attachment.html>