[swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

[Nicola Salmoria]

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 <scanon at apple.com> wrote:

> On Apr 26, 2016, at 10:03 AM, Nicola Salmoria via swift-evolution <
> swift-evolution at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160426/439b117e/attachment.html>