Unrelated to this discussion about comparison operators, please remember to put back .abs() or .absoluteValue() somewhere in FloatingPoint. Thanks!
On Tue, Apr 26, 2016 at 12:07 PM, Nicola Salmoria via swift-evolution < [email protected]> wrote: > If performance is the only reasons to have a separate method, perhaps it > might make sense to have a note about this in the isLessThanOrEqualTo > description, and provide a default implementation that calls down on isLess > and isEqual. > > Nicola > > > On Tue, Apr 26, 2016 at 4:59 PM, Stephen Canon <[email protected]> wrote: > >> On Apr 26, 2016, at 10:03 AM, Nicola Salmoria via swift-evolution < >> [email protected]> wrote: >> >> >> it should be enough to do >> >> func <= <T: FloatingPoint>(lhs: T, rhs: T) -> Bool >> { >> return lhs.isLess(than: rhs) || lhs.isEqual(to: rhs) >> } >> >> Or is there some case of x, y where (x <= y) is true but (x < y) and (x >> == y) are both false? >> >> >> No, these are always equivalent. >> >> However, there is a problem with this approach: the compiler knows about >> the built-in floating-point types (Float, Double, Float80) and their >> aliases (CGFloat, etc) and can fuse the two comparisons into a single >> hardware operation. However, for soft-float types, without a >> lessThanOrEqual method, there is no single comparison that the compiler >> could fuse these to. >> >> In some cases, if they are simple enough, the compiler may be able to >> actually fuse the bodies of the two comparison operations, but we can’t >> reasonably depend on that happening or even being possible in all cases. >> So for performance, it’s important that there be an actual less than or >> equal to method. >> >> – Steve >> > > > _______________________________________________ > 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
