Also, maximum() should probably return y if x == y to be consistent with max() <https://github.com/apple/swift/blob/master/stdlib/public/core/Algorithm.swift#L38>, preserving stable ordering for (x, y) = (min(x, y), max(x, y)). I think IEEE 754 leaves the x == y case unspecified. Currently we have the guarantee below.
/// (…) Returns `x` if `x >= y`, `y` if `y > x` (…)static func maximum(x: Self, _ y: Self) -> Self Patrick On Sun, May 1, 2016 at 9:03 AM, Patrick Pijnappel < patrickpijnap...@gmail.com> wrote: > Am I correct in assuming that this would also eliminate the hidden > associatedtype > _BitsType currently preventing non-stdlib conformances? > > On Wed, Apr 27, 2016 at 2:04 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> I thought you'd mentioned that AbsoluteValuable conformance was removed >> for a reason and that the method would be added to FloatingPoint? >> Otherwise, it seems like conformance to AbsoluteValuable would be much the >> same... >> >> >> On Tue, Apr 26, 2016 at 6:54 PM, Stephen Canon <sca...@apple.com> wrote: >> >>> Do you actually want a method added, or just conformance to >>> AbsoluteValuable? >>> >>> – Steve >>> >>> On Apr 26, 2016, at 7:41 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>> 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 < >>> swift-evolution@swift.org> 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 <sca...@apple.com> >>>> wrote: >>>> >>>>> On Apr 26, 2016, at 10:03 AM, Nicola Salmoria via swift-evolution < >>>>> swift-evolution@swift.org> 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 >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution