On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull <jh...@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.
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
