<div dir="ltr">On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull <span dir="ltr">&lt;<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_5034690051034842618Apple-interchange-newline"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">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.</span></div></blockquote></div><br></span><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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...</div></div></blockquote><div><br></div><div>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?`.</div><div><br></div><div>Just as Swift String conforms to Unicode standards, FloatingPoint conforms to IEEE standards. You&#39;d have to come up with enormous benefits to justify breaking that. Doing so for Swift 4 is plainly a non-starter.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>Thanks,</div><div>Jon</div></div></blockquote></div><br></div></div>