on Sun Apr 16 2017, Xiaodi Wu <[email protected]> wrote: > 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.
+1 -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
