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

[Stephen Canon]

> On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
> A few things…
> 
> First, something absent: I'm a little bit concerned by the act that there's no means to convert between different concrete FloatingPoint types. Something like the IntMax mechanism in Swift 2's IntegerType might be useful, though there may be good reasons not to do that.

There are concrete conversions between all built in float types.  Those aren’t going away.  Are you saying that you want init(_ value: Float) etc to be protocol requirements?

>> public protocol FloatingPoint: Comparable, IntegerLiteralConvertible {
>> public protocol BinaryFloatingPoint: FloatingPoint, FloatLiteralConvertible {
> 
> Any reason why FloatLiteralConvertible isn't on FloatingPoint?

It doesn’t make sense for non-radix-2 types; you would change bases multiple times.

>>  prefix func +(x: Self) -> Self
> 
> Does this actually do anything, or is it a no-op? If the latter, should it just be a free function rather than part of the protocol? Or maybe even part of the literal syntax that can't be applied to variables at all?
> 
>>  static func minimum(x: Self, _ y: Self) -> Self
>>  static func maximum(x: Self, _ y: Self) -> Self
>>  static func minimumMagnitude(x: Self, _ y: Self) -> Self
>>  static func maximumMagnitude(x: Self, _ y: Self) -> Self
> 
> These all take two operands, but I can't think of a reason for that. Might they be better off as variadic? (Or is the "implementation hook" comment meant to indicate that the variadic form of the `max` free function will use these calls?)

Correct, the free functions will use these.

>>  func isEqual(to other: Self) -> Bool
>>  func isLess(than other: Self) -> Bool
>>  func isLessThanOrEqual(to other: Self) -> Bool
> 
> I'm still not sure why these are methods instead of operators.
> 
> (I also share others' concern about the argument label on `isLessThanOrEqual`.)

There’s lots of concern, and very few suggestions of anything better.  The only thing that seems workable is maybe `isLessThanOrEqualTo(_:)`, which is inconsistent with the other comparisons, but maybe that’s the right thing to do anyway.

>>  func isUnordered(with other: Self) -> Bool
>>  func isTotallyOrdered(with other: Self) -> Bool
> 
> I think these features should be folded into Comparable, but I'll start a different thread about that. For the moment, these seem fine.
> 
>>  func isEqual<Other: BinaryFloatingPoint>(to other: Other) -> Bool
>>  func isLess<Other: BinaryFloatingPoint>(than other: Other) -> Bool
>>  func isLessThanOrEqual<Other: BinaryFloatingPoint>(to other: Other) -> Bool
>>  func isUnordered<Other: BinaryFloatingPoint>(with other: Other) -> Bool
>>  func isTotallyOrdered<Other: BinaryFloatingPoint>(with other: Other) -> Bool
> 
> Can you provide some color on these? Loosening the typing in this way is quite unusual in Swift; you're not doing it for arithmetic operators, for instance.

Heterogeneous comparisons have an unambiguous result type and correct result.  Heterogeneous arithmetic does not (at least, not in all cases), so it’s a more difficult language design problem.

>>  init(nan payload: Self.RawSignificand, signaling: Bool)
> 
> The discussion doesn't mention why this isn't part of the protocol. Any commentary? (I'm guessing it's "you need to know the type anyway to do anything useful with the payload", but I'm not sure, and it's useful to document the reasons for these sorts of decisions)

Yup, that’s exactly right.  I’ll add a note.

>> 	* What is your evaluation of the proposal?
> 
> I think it's a huge improvement.
> 
>> 	* Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Yes. The current floating-point protocols are inadequate.
> 
>> 	* Does this proposal fit well with the feel and direction of Swift?
> 
> Yes.
> 
>> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> I don't have much experience with floating-point abstractions of this sort, but as far as the end-user APIs are concerned, I really like these APIs.
> 
>> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> Participated in the previous round of discussion as well as this one.

Thanks for the feedback!
– Steve