<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=""><blockquote type="cite" class="">On Jul 22, 2016, at 6:55 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 22, 2016, at 5:50 PM, Stephen Canon <<a href="mailto:scanon@apple.com" class="">scanon@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div class=""><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Sorry if it wasn’t clear. I’m not suggesting taking that away. I’m asking whether we have considered defining `==` on floating point types to be the equivalence relation that is proposed for `areSame` and giving the domain specific operation a different name. </div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Maybe this would break with convention too much, but it would feel much more intuitive (to me at least - although I am admittedly not a numerics expert).</div></div></blockquote></div><br class=""><div class="">IEEE754 doesn’t specify language bindings, so it *is* allowed to e.g. provide an `isEqualIEEE754` predicate and make `==` do something else.</div><div class=""><br class=""></div><div class="">However, doing so would break with the precedent set by … well, every mainstream programming language of the past 30 years, and make porting existing numeric code an error-prone process for anyone who hadn’t carefully studied this particular aspect of Swift.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Thanks for chiming in Steve. I know it isn’t a decision to be taken lightly for sure and breaking the convention may well not be the right idea. I just wanted to point out that maybe it is possible to consider this without giving up IEEE floating point conformance.</div><div class=""><br class=""></div><div class="">The fact that `==` isn’t always an equivalence relation makes me sad but maybe the industry is too far down that rabbit hole to consider anything else…</div></div></div></div></blockquote><br class=""></div><div>The two *major* issues I foresee with doing this both have to do with implementing / porting existing code.</div><div><br class=""></div><div>1. There exists an enormous amount of code (and pseudo-code in publications) that predates the existence of `isnan` in whatever language the code was written with. These codes explicitly use `x != x` as a test for NaN, and `x == x` as a check for non-NaN. Users transcribing / porting such code are unlikely to know that they need to change these statements, frequently resulting in bugs that they won’t find unless their test set contains explicitly invalid inputs.</div><div><br class=""></div><div>2. I don’t think it would make sense to make `==` an equivalence relation without also making `<` a strict total order. This would cause bigger problems than `==`, because a lot of numeric code uses something like:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>while (residual > tolerance) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>// refine</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div>to check for convergence, with a test for NaN following the loop to detect failures; if `<` is made a strict total order, then `NaN` needs to be ordered either before or after finite numbers, and either option will break some loops written in this form.</div><div><br class=""></div><div>This sort of code is frequently copied out of books like “Numerical Recipes” with minimal adaptation to whatever the target language is, and even minimal awareness of the precise semantics of the target language. The great success of IEEE 754 is that this doesn’t *usually* matter; the code works anyway. Breaking that property seems somewhat antithetical to the safety goals of the language.</div><div><br class=""></div><div>There’s also a lesser performance concern (we have 35 years of floating-point hardware designed around the IEEE 754 comparison operators; so doing almost anything else will produce small performance hiccups on most hardware, and large performance issues on some hardware). This isn’t my major worry, however; we’re trying to design a language for the *next* 35 years (or more), after all, and most of that hardware hasn’t been designed yet.</div><div><br class=""></div><div>– Steve</div></body></html>