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

[Patrick Pijnappel]

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 at 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 <scanon at 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.wu at 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 at 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 <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
>>>>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160501/2dd97e47/attachment.html>