<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 27, 2017, at 3:06 AM, Jonathan Hull via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Oct 26, 2017, at 11:44 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:jhull@gbis.com" target="_blank" class="">jhull@gbis.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">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.<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">We definitely have different world views. I see the handling of NaN as a legacy/compatibility issue due to committee/vendor politics from the 1980’s. I am pretty sure if they could do it over with modern tech, we would just have isNan() and NaN == NaN… or we might just have optionals instead.</div></div></div></blockquote><br class=""></div><div>For a sufficiently non-mathematical definition of "logic"...</div><div><br class=""></div><div><div>Logically speaking, NaN == NaN, but <i class="">mathematically</i> speaking it does not. NaN is, by definition, not a number, so asking if it's equal to itself or anything else is a mathematically meaningless question (same goes for < and >). If you're keeping track of <i class="">why</i> the answer is NaN, then there's at least a basis for discussing the matter... like in `1.0 == sin(x)/x`, where x is 0... Well, 0/0 is classic example of an undefined result, but the limit of sin(x)/x as x approaches 0 does equal 1, so in <i class="">some</i> sense -- AFAIK a very non-rigorous sense -- you'd be not <i class="">entirely</i> wrong to say that `1 == sin(0)/0` could kinda sorta be considered to be "proximately related to `true`" or something. For `==` to know that, though, .nan would need to carry the relevant closure and its arguments as a payload so that some other bits of logic could know how we got to 0/0, and `==` would need in-hardware calculus to verify, in a timely manner, that the limit both exists and is the same from both sides (or I suppose the `/` op could do it... that'd save on the payload requirements, but you're still stuck doing calculus in hardware). Since that's prohibitively impractical, if `==` <i class="">has</i> to give a boolean answer, it is much more correct to say "NaN != NaN". One could argue that the semantics of Swift's `==` ought be closer to "matches" than "equals", though, which I think is what Xiaodi is getting at.</div><div><br class=""></div></div><div class="">- Dave Sweeris</div></body></html>