[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[David Zarzycki]

> On Oct 24, 2017, at 14:55, Ben Cohen via swift-dev <swift-dev at swift.org> wrote:
> 
> There really is no way to square this circle. Every option is going to have downsides. We have to balance correctness, least surprise/most expected behavior for most people, and consistency. For me, making generic use of Equatable and Comparable stick to the documented conformance generically, while keeping FP-specific uses the way they are, is the least bad option. 

Hi Ben,

Out of curiosity, what do you think about breaking Equatable into two protocols: Equatable and Substitutable? The former would be defined in terms of mathematics, while the latter is simple to define and usable by collections, etc. For example, while +0 equals -0, they are not substitutable (because 1.0 / +0.0 == +inf BUT 1.0 / -0.0 == -inf). In the case of NaNs, substitutability would depend on the NaN payload being the same or not (because some later subsystem might interpret the NaN payload). Finally, and unless I’m missing something, floating-point “substitutability” would translate to bitwise equality at the hardware level, which is nice from a performance perspective.

On the topic of sorting, we could do the same thing, where we break Comparable into two protocols: Comparable and Sortable. The former would be defined in terms of mathematics, while the latter has no mathematical obligation and therefore values like +0 and -0 can be consistently sorted. The same goes of NaNs with payloads (they can be sorted). And finally, at the hardware level, this should be quite efficient because of how the floating point bits are laid out (in that an integer comparison of FP bits should work for this Sortable proposal).

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171024/00bf2f2e/attachment.html>