I can support that.
> On Oct 20, 2017, at 10:21 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > > On Fri, Oct 20, 2017 at 10:10 Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: >> On Oct 20, 2017, at 9:36 AM, Xiaodi Wu via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> >> On Fri, Oct 20, 2017 at 07:21 David Zarzycki <d...@znu.io >> <mailto:d...@znu.io>> wrote: >> >> >>> On Oct 20, 2017, at 07:51, Xiaodi Wu via swift-dev <swift-dev@swift.org >>> <mailto:swift-dev@swift.org>> wrote: >>> >>> On Fri, Oct 20, 2017 at 1:22 AM, Jonathan Hull <jh...@gbis.com >>> <mailto:jh...@gbis.com>> wrote: >>> +1 for trapping unless using &==. In the case of ‘Float?’ we could also >>> map to nil. >>> >>> This is probably a more appropriate discussion for evolution though... >>> >>> >>>> On Oct 19, 2017, at 9:48 PM, Brent Royal-Gordon via swift-dev >>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>>> >>>>> On Oct 19, 2017, at 4:29 PM, Xiaodi Wu via swift-dev <swift-dev@swift.org >>>>> <mailto:swift-dev@swift.org>> wrote: >>>>> >>>>> D) Must floating-point IEEE-compliant equivalence be spelled `==`? >>>>> >>>>> 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. >>>> >>>> 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. >>>> >>>> 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. >>> >>> >>> 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. >>> >>> 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. >> >> 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". >> >> In short: what IEEE requires of floating-point hardware is separable from >> IEEE’s opinions about language/library design. >> >> 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. >> >> 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. >> >> 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. >> >> But I really don’t want to discuss this at all here. The topic of this >> thread is about the semantics of Equatable. > > On the other hand, changing the spelling of IEEE `==` was option in your > opening post represented by demand 4 and question D. > >> 4) IEEE-compliant floating-point equivalence must be spelled `==` and not >> some alternative such as `&==`. > >> D) Must floating-point IEEE-compliant equivalence be spelled `==`? > >> >> >> 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. > > > 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. > > 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. > > I agree. > > 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. > > I think this is reasonable as well. > > 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`. > > 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. > >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >> <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
