> Le 18 avr. 2017 à 17:40, Joe Groff <jgr...@apple.com> a écrit : > > >> On Apr 18, 2017, at 1:34 AM, Gwendal Roué <gwendal.r...@gmail.com> wrote: >> >>> >>> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution >>> <swift-evolution@swift.org> a écrit : >>> >>>> >>>> On Apr 17, 2017, at 9:40 PM, Chris Lattner <clatt...@nondot.org> wrote: >>>> >>>> >>>>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> >>>>>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>>>>> <swift-evolution@swift.org> wrote: >>>>>> >>>>>> For example, I expect `XCTAssertEqual<T : FloatingPoint>(_:_:)` to be >>>>>> vended as part of XCTest, in order to make sure that >>>>>> `XCTAssertEqual(resultOfComputation, Double.nan)` always fails. >>>>> >>>>> Unit tests strike me as an example of where you really *don't* want level >>>>> 1 comparison semantics. If I'm testing the output of an FP operation, I >>>>> want to be able to test that it produces nan when I expect it to, or that >>>>> it produces the right zero. >>>> >>>> I find it very concerning that == will have different results based on >>>> concrete vs generic type parameters. This can only lead to significant >>>> confusion down the road. I’m highly concerned about situations where >>>> taking a concrete algorithm and generalizing it (with generics) will >>>> change its behavior. >>> >>> In this case, I think we're making == do exactly what you want it to do >>> based on context. If you're working concretely with floats, then you get >>> floating-point behavior like you'd expect. If you're working with >>> generically Equatable/Comparable things, then you're expecting the abstract >>> guarantees of interchangeability and total ordering that implies, and you >>> don't want to have to think about the edge cases of weird types that >>> violate those constraints. I also doubt that this will cause problems in >>> practice. >> >> "then you're expecting the abstract guarantees of interchangeability and >> total ordering that implies" >> >> Joe, please: I'm very glad that you are expert in so many subject - I'd love >> to have your job - but please keep track of average joes that have to >> scratch their heads whenever they have to deal with nans and infinites and >> subnormals and all those weird floating beasts. They already scratch their >> heads with the idiosyncrasies of Swift protocols. >> >> Please keep equality simple. > > I would argue that keeping equality simple is exactly what this proposal > achieves, since you *don't* need to worry about nans or positive/negative > zero or other floating-point strangeness every place you use == abstractly. > You have to opt in to the idiosyncratic behavior by working concretely with > floats.
Cool, a brand new Swift chapter added to "What Every Computer Scientist Should Know About Floating-Point Arithmetic" :-) Gwendal _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
