On Tue, Apr 25, 2017 at 12:45 AM, Jonathan Hull via swift-evolution < [email protected]> wrote:
> +1 > > What I am arguing for is #2. We have two different expectations and we > need to be explicit about which is being used. Furthermore, I am arguing > that if one of them is going to be the default (and use the ‘==‘ and ‘<‘ > symbols), it needs to be the strict equality/total ordering version, since > that is what every other Swift type is modeling, and IEEE is only > applicable to floating point. > Then it's an insoluble problem, because (and for good reasons) there are those who consider anything other than `.nan != .nan` to be a non-starter. My attempt to convince people that maybe we could just make that expression trap instead of giving an answer did not, evidently, win over too many fans. But I tend to sympathize with the numerics crowd that `.nan == .nan` would be disastrous for Swift when it comes to numerics. No other (common) language behaves that way. > On Apr 24, 2017, at 9:44 PM, David Waite via swift-evolution < > [email protected]> wrote: > > > > I still think this is a naming conflict more than anything else. > > > > The first expectation is that equatable and comparable provides strict > equality and strict total ordering, and that those are exposed via > operators. The other expectation is that floating point abides by the IEEE > rules which have neither of these, and are exposed via operators. > > > > Either: > > 1. the operators need to do different things in different contexts > > 2. we need different methods/operators to indicate these different > concepts > > 3. Equatable and comparable need to be altered to no longer require > strict equality and strict total ordering (and all generic algorithms based > on equatable/comparable need to be checked that they still work) > > 4. floating point numbers need to explicitly not be equatable/comparable > to prevent their usage in generic algorithms requiring strict behavior. > > 5. We break away from IEEE behavior and provide only strict equality and > strict total ordering > > > > (I tried to sort these roughly in order of feasibility) > > > > Are there any other options? > > > > -DW > > > >> On Apr 24, 2017, at 9:50 PM, Dave Abrahams via swift-evolution < > [email protected]> wrote: > >> > >> > >> on Mon Apr 24 2017, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: > >> > >>> On Mon, Apr 24, 2017 at 9:06 PM, Jonathan Hull via swift-evolution < > >>> [email protected]> wrote: > >>> > >>>> As I am thinking about it more, this means that for == and < > >>>> > >>>> NaN == NaN > >>>> -0 == +0 > >>>> +Inf < NaN > >>>> > >>>> Since this would break from IEEE, > >>> > >>> Yeah, as Steve mentioned, it's a huge deal to break from IEEE rules. > >> > >> Allow me to put it even more strongly: I consider reinventing how > >> floating point works to be a massive undertaking comparable to > >> supplanting the Unicode standard with something better. I have no doubt > >> that it could be done by somebody, somewhere, someday, but it would be > >> easy to do something much worse than what IEEE has done, and getting it > >> right would occupy so much of this group's time that we couldn't hope to > >> accomplish anything else, if we even had the expertise—I know I don't! > >> Doing anything in this area that is not firmly rooted in existing > >> standards and practices is not an option I'm willing to pursue. > >> > >> -- > >> -Dave > >> _______________________________________________ > >> swift-evolution mailing list > >> [email protected] > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
