On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull <[email protected]> wrote:
> > On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > The point is that, when you manipulate two real numbers, sometimes there > is no numeric result. You cannot simply wish this away with a new numeric > type because it is not an artifact of _modeling_ real numbers but rather > intrinsic to mathematics itself. > > > I agree with the rest of what you said, but I have to disagree on this > point. What I think he is saying is that, in Swift, we really should be > representing the NaN case as an optional instead of a magic value on the > type itself (similar to how swift uses an optional instead of NSNotFound). > > In fact, that might be an actual option here. For ‘Double?’ the compiler > could use the bit pattern for NaN internally to represent .none (I believe > it does similar tricks to save space with other optional types). Then > disallow reference to NaN within swift code. Functions or operations which > could produce NaN would either have to produce an optional or trap in case > of NaN. (e.g. the trig functions would likely return an optional, and 0/0 > would trap). > > I think it would actually lead to much better code because the compiler > would force you to have to explicitly deal with the case of optional/NaN > when it is possible. Migration would be tricky though... > This is essentially a cosmetic renaming from `Double` to `Double?`. There are rules for propagating NaN which numeric algorithms expect. For example, `cos(.nan)` returns a value. If your design is to work, every function that takes a `Double` will need to take a `Double?`. Just as Swift String conforms to Unicode standards, FloatingPoint conforms to IEEE standards. You'd have to come up with enormous benefits to justify breaking that. Doing so for Swift 4 is plainly a non-starter. Thanks, > Jon >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
