> On Apr 18, 2017, at 9:47 AM, Gwendal Roué <[email protected]> wrote: > > >> Le 18 avr. 2017 à 17:40, Joe Groff <[email protected]> a écrit : >> >> >>> On Apr 18, 2017, at 1:34 AM, Gwendal Roué <[email protected]> wrote: >>> >>>> >>>> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution >>>> <[email protected]> a écrit : >>>> >>>>> >>>>> On Apr 17, 2017, at 9:40 PM, Chris Lattner <[email protected]> wrote: >>>>> >>>>> >>>>>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>>>>>> <[email protected]> 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" :-)
IMO, it will be a victory if the Swift edition can be titled "What Every Computer Scientist *Who Uses Floats* Should Know About Them", and everyone else who doesn't think about floating-point every day can sleep easy at night without Kahan's ghost hiding under their bed. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
