[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Xiaodi Wu]

On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull <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.

Then you have your safe/friendly Swift Floating point type(s) which just
> have no concept of NaN at all (and probably a single notion of zero). You
> have a failable initializer from the IEEE versions. These types conform to
> Equatable/Hashable/Comparable.  Care is taken with internal methods so that
> NaN can’t creep into the type.
>
> How do we handle math functions which might fail?  We do the same thing we
> do in the rest of Swift... those functions return an optional.
>
> When reading in data from the outside world or C code, you would use the
> IEEE versions and then either convert or do your calculations directly.
> They would probably also be used for things like accelerate.  But most
> code, where the values come from user input or literals, would never even
> have to touch the IEEE version.
>
> The advantage here is that you get full speed all the time, even in
> generic contexts.  You just can’t use the IEEE versions directly in generic
> contexts. You would have to convert them, which is a one-time cost (or use
> them non-generically).
>

Again, generics and protocol-based numerics are important; that's what
Numeric is all about. Any idea that doesn't make this possible is a
non-starter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171027/e3920cb5/attachment.html>