[swift-dev] Rationalizing FloatingPoint conformance to Equatable
xiaodi.wu at gmail.com
Fri Oct 27 01:44:13 CDT 2017
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev