I certainly don't want to restrain anyone from improving on the floating point status quo. There's surely much to do. I apologize for my not-so-constructive messages. Maybe I'm surprised that this was one of the goals of Swift.
Floats and Strings are efficient ways to test comparison APIs indeed. Gwendal > Le 18 avr. 2017 à 18:58, Joe Groff <jgr...@apple.com> a écrit : > > >> On Apr 18, 2017, at 9:47 AM, Gwendal Roué <gwendal.r...@gmail.com> wrote: >> >> >>> 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" :-) > > 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
