[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Chris Lattner]

> On Oct 26, 2017, at 11:44 PM, Xiaodi Wu via swift-dev <swift-dev at swift.org> wrote:
> 
> On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull <jhull at gbis.com <mailto:jhull at gbis.com>> wrote:
> One completely different idea, which I brought up a year or so ago, is to do what we do with pointers around this.  That is you have your fast/unsafe IEEE Floats/Doubles/etc that have a scarier name.  These do not conform to Equatable or Comparable, but have their own version of IEEE equality/comparison. Let’s spell it &== and &< to make it feel different so the users consider the possibility of NaN.  They don’t have any notion of hashability.
> 
> As I wrote in my reply to Greg, IEEE equality and comparison is _the_ best approximation of mathematical equality and comparison suitable for floating-point types. If another one were superior, then floating-point experts would have designated that as the standard.
> 
> Swift correctly exposes only one concept of equality for floating-point types. It is and should be IEEE equality. People should be encouraged and not scared to use it. NaN is and should continue to exist as a concept. Yes, IEEE-compliant floating point is hard; the only thing harder than IEEE-compliant floating point is non-IEEE-compliant floating point.
> 
> This thread is meant to discuss how to reconcile this scenario with the semantics of Equatable.

I haven’t been following this thread closely, but I agree that solving this by making floating point numbers substantially harder to work with (e.g. by having to explicitly reason about NaN’s everywhere) is the wrong direction to go.

Is the intersection of NaN handling and Equality actually causes problems in practice for people?

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171028/afac9ba2/attachment.html>