[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Sat, Apr 15, 2017 at 5:25 PM, Karl Wagner via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> I think consideration should be given to a design that achieves a
> user-facing but not onerous differentiation between level 1 and level 2
> equality. However, the only one I can think of is essentially a different
> shade of the `PartiallyComparable` alternative already outlined in the
> document.
>
>
> I am *deeply* opposed to such a protocol.  It is purely syntactic in
> nature and thus useless for correctly constraining generic algorithms.
> People will use it anyway, resulting in algorithms that statically
> accept, but are incorrect for, floating point.  In my opinion there's
> only one feasible answer that doesn't use the static/dynamic distinction
> we've proposed: throw IEEE semantics under the bus, making it available
> only under a different syntax.
>
> This would be a drastic move whose primary downside is that floating
> point code ported from C would need to be carefully audited and may
> become less easy to read.  But at least it would be viable.
>
>
> Yeah, I think it should really be considered. An IEEEComparable protocol,
> defining methods such as “isEqualTo”, “isLessThan”, etc would make the
> distinction clearer.
>
> And, as you said, not many people really know or care about the IEEE
> comparison special cases. It’s a bit of an expert field. Is it that bad to
> ask experts who explicitly care about the order between +/- 0 or different
> NaNs to use a special function for that behaviour?
>

Let's be clear, currently `+0.0 == -0.0`, and this is very important. With
this proposal `+0.0 != 0.0` in the generic context, which has useful
properties, but is not what you want when working with the concrete type
Double.

Also, currently, `.nan != .nan`, which is also very important. It is not
about "different types of NaN," as even the same type of NaN compares
unequal to itself. Some very basic numeric algorithms that operate on
concrete FP types expect NaN not to equal anything. With this proposal
`.nan == .nan` in the generic context, which is useful for generic sorting
but not what you want when working with Double.


> I suppose it needs to be weighed up with something like: (number of people
> ignorant of the difference) x (probability of unexpected result) x
> (significance of unexpected result, if estimable).
>
> How often do non-floating point experts even use FloatingPoint as a
> protocol (as opposed to Float/Double)?
>
> - Karl
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170415/4ba9ef64/attachment.html>