On Fri, Oct 20, 2017 at 10:10 Matthew Johnson <matt...@anandabits.com> wrote:
> On Oct 20, 2017, at 9:36 AM, Xiaodi Wu via swift-dev <swift-dev@swift.org> > wrote: > > > On Fri, Oct 20, 2017 at 07:21 David Zarzycki <d...@znu.io> wrote: > >> >> >> On Oct 20, 2017, at 07:51, Xiaodi Wu via swift-dev <swift-dev@swift.org> >> wrote: >> >> On Fri, Oct 20, 2017 at 1:22 AM, Jonathan Hull <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> wrote: >>> >>> On Oct 19, 2017, at 4:29 PM, Xiaodi Wu via swift-dev < >>> 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 > https://lists.swift.org/mailman/listinfo/swift-dev > > >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
