<div><br><div class="gmail_quote"><div dir="auto">On Fri, Oct 20, 2017 at 10:10 Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<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><blockquote type="cite"><div>On Oct 20, 2017, at 9:36 AM, Xiaodi Wu via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:</div><br class="m_-1759178379412537030Apple-interchange-newline"><div><div><br><div class="gmail_quote"><div dir="auto">On Fri, Oct 20, 2017 at 07:21 David Zarzycki <<a href="mailto:dave@znu.io" target="_blank">dave@znu.io</a>> wrote:<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;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Oct 20, 2017, at 07:51, Xiaodi Wu via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:</div><br class="m_-1759178379412537030m_-4110680497984621742Apple-interchange-newline"><div><div>On Fri, Oct 20, 2017 at 1:22 AM, Jonathan Hull <span><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>></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">+1 for trapping unless using &==. In the case of ‘Float?’ we could also map to nil.<div><br></div><div>This is probably a more appropriate discussion for evolution though...<br><div><div><br></div><div><br><div><div><blockquote type="cite"><div><div class="m_-1759178379412537030m_-4110680497984621742h5"><div>On Oct 19, 2017, at 9:48 PM, Brent Royal-Gordon via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:</div><br class="m_-1759178379412537030m_-4110680497984621742m_2743765292807577601Apple-interchange-newline"></div></div><div><div><div class="m_-1759178379412537030m_-4110680497984621742h5"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div>On Oct 19, 2017, at 4:29 PM, Xiaodi Wu via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:</div><br class="m_-1759178379412537030m_-4110680497984621742m_2743765292807577601Apple-interchange-newline"><div><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">D) Must floating-point IEEE-compliant equivalence be spelled `==`?</div><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"><br></div><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">In my view, this is something open for debate. I see no reason why it cannot be migrated to `&==` if it were felt that `==` *must* be a full equivalence relation. I believe this is controversial, however.</div></div></blockquote><br></div><div>I actually got partway through writing up a pitch on this yesterday, but my opinion is that NaNs are so exceptional, and so prone to misuse, that we ought to treat them like integer arithmetic overflows: trap when they're detected, unless you use an `&` variant operator which indicates you know what you're doing.</div><div><br></div><div>I strongly suspect that, in practice, most float-manipulating code is not prepared to handle NaN and will not do anything sensible in its presence. For example, Apple platforms use floating-point types for geometry, color components, GPS locations, etc. Very little of this code will do anything sensible in the presence of a NaN. Arguably, it'd be better to exclude them through the type system, but I don't think that's a realistic possibility—we would need to have done that in a more source-break-friendly era. But that doesn't have to mean we're completely stuck.</div></div></div></div></div></blockquote></div></div></div></div></div></div></blockquote><div><br></div><div>Built-in floating point operators, as well as libc/libm math functions, are designed to propagate NaN correctly. This is not meant to be a thread about NaN, and we need to be cautious to define the scope of the problem to be solved from the outset. The tendency of having ever-expanding discussion where issues such as method names turn into discussions about the entire standard library go nowhere.</div><div><br></div><div>The question here is about `==` specifically and how to accommodate partial equivalence relations. For sanity, we start with the premise that NaN will forever be as it is.</div></div></div></div></div></blockquote><br></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>I support Jonathan’s argument. If Swift wants to trap on NaN to improve self-consistency and simplicity, then the tradeoff might be worth it. The alternative, teaching the Equality protocol about NaNs, feels like “the tail wagging the dog".</div><div><br></div><div>In short: what IEEE requires of floating-point hardware is separable from IEEE’s opinions about language/library design.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">IEEE 754 requires certain behaviors of conforming implementations and is meant to allow for portable use of floating point. Swift’s floating point facilities are conformant to that standard, and breaking IEEE 754 conformance has been repeatedly stated to be a non-starter.</div><div dir="auto"><br></div><div dir="auto">The essential idea behind quiet NaN is that it can be used as input in operations that take floating point values without raising errors. Since breaking IEEE 754 conformance is a non-starter, trapping on NaN is outside the realm of available solutions.</div><div dir="auto"><br></div><div dir="auto">It has been pointed out, however, that IEEE does not require a specific syntax for floating point equivalence, hence the question of whether it can be spelled differently. However, trapping on NaN is emphatically not an option.</div><div dir="auto"><br></div><div dir="auto">But I really don’t want to discuss this at all here. The topic of this thread is about the semantics of Equatable.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>On the other hand, changing the spelling of IEEE `==` was option in your opening post represented by demand 4 and question D.</div><div><br></div></div></div><div style="word-wrap:break-word"><blockquote type="cite">4) IEEE-compliant floating-point equivalence must be spelled `==` and not some alternative such as `&==`.</blockquote></div><div style="word-wrap:break-word"><blockquote type="cite">D) Must floating-point IEEE-compliant equivalence be spelled `==`?</blockquote></div><div style="word-wrap:break-word"><blockquote type="cite"><br><br><div><div><div>In my view, this is something open for debate. I see no reason why it cannot be migrated to `&==` if it were felt that `==` *must* be a full equivalence relation. I believe this is controversial, however.</div></div></div></blockquote></div><div style="word-wrap:break-word"><blockquote type="cite"></blockquote><div><br></div>What you call the "proximate issue” goes away if the solution to what you call the “distal issue” involves requiring `Equatable` conforming types to provide an implementation of `==` that represents a full equivalence relation. It looks to me like many people are suggesting that this is exactly what we should do. <div><br></div><div>I not a numerics expert by any means and am therefore cautious to offer my opinion, but rejecting demand 4 appears to be the best option to me. One advantage of this approach in addition to providing a full equivalence relation for floating point’s equatable conformance is that it makes it clear when an algorithm was written with IEEE semantics in mind or when the programmer did not desire or may not be aware of IEEE semantics.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">I agree.</div><div dir="auto"><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></blockquote><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>IMO, the more general issue of partial equivalence relations should be orthogonal. I don’t believe NaN should drive the semantic requirements of `Equatable` and I don’t believe IEEE should prevent floating point types from providing an Equatable conformance. </div></div></blockquote><div dir="auto"><br></div><div dir="auto">I think this is reasonable as well.</div><div dir="auto"><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>Perhaps this is a sign of my ignorance of numerics, but that’s the solution this seems to make the best tradeoffs. I am happy to let others decide whether `NaN == NaN` should trap or return `true`.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">Trapping violates the requirements of Equatable and, I think, also IEEE edicts; NaN == NaN would be the only solution if we dispense with demand 4.</div><div dir="auto"><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></blockquote><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><blockquote type="cite"><div>
_______________________________________________<br>swift-dev mailing list<br><a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br></div></blockquote></div><br></div></div></blockquote></div></div>