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

[Patrick Pijnappel]

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 <
patrickpijnappel at 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 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/7135ddae/attachment.html>