[swift-evolution] [Proposal draft] Enhanced floating-point protocols

[Stephen Canon]

> On Apr 14, 2016, at 10:47 PM, davesweeris at mac.com wrote:
> 
> In general, I think this is fantastic. In particular, I *really* like the notion that `BinaryFloatingPoint` conforms to `FloatingPoint`. I would do a few things differently, though:
>> On Apr 14, 2016, at 6:55 PM, Stephen Canon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> public protocol FloatingPoint: SignedArithmetic, Comparable {
>>   ...
>>   /// The greatest finite number.
>>   ///
>>   /// Compares greater than or equal to all finite numbers, but less than
>>   /// infinity.  Corresponds to the C macros `FLT_MAX`, `DBL_MAX`, etc.
>>   /// The naming of those macros is slightly misleading, because infinity
>>   /// is greater than this value.
>>   static var greatestFiniteMagnitude: Self { get }
>>   ...
>> }
> 
> Why put this in FloatingPoint? The concept is valid for any real type (IMHO, it’s valid for rectangular Complex/Quaternion/etc types as well... I’m not sure if it is for the various polar formats, though). I think a better place for it is either in `Arithmetic`, or another protocol to which `Arithmetic` conforms:
> 
> protocol HasMinAndMaxFiniteValue {
>     static var maxFinite: Self {get} // I think “max”/“min" are clear enough (especially if the docs are explicit), but I understand the objection
>     static var minFinite: Self {get} // 0 for unsigned types
> }

As mentioned in reply to Brent, there may very well be Arithmetic types without a real notion of magnitude (modular integers).  There’s also a complication that the magnitude of a Complex<T> shouldn’t be complex, but rather real, and also isn’t usually representable as a T (the one exception is polar forms, where it *is* representable =).

> This would unify the syntax for getting a numeric type’s min or max finite value across all the built-in numeric types (this means that `Int.max` would become `Int.maxFinite`). Similarly, IMHO infinity shouldn’t be tied to floating point types. While it’s true that the *native* integer types don’t support infinity, arbitrary precision integer types might.
> 
> protocol HasInfinity {
>     static var infinity: Self {get}
> }

I think that integer max and min behave sufficiently differently from the FloatingPoint quantities that it’s not particularly useful to unify their names.  Most obviously, all integers between min and max are representable for integers, and this is very much not the case for floating point types.

> I’d restructure this a bit:
> protocol Arithmetic { //AFAIK *all* numeric types should be able to do these
>     init()
>     func adding(rhs: Self) -> Self
>     mutating func add(rhs: Self)
>     func subtracting(rhs: Self) -> Self
>     mutating func subtract(rhs: Self)
> }
> protocol ScalarArithmetic : Arithmetic { //These can be iffy for non-scalar types
>     func multiplied(by rhs: Self) -> Self
>     mutating func multiply(by rhs: Self)
>     func divided(by rhs: Self) -> Self
>     mutating func divide(by rhs: Self)
> }
> 
> Multiplication isn't always defined for any two arbitrarily-dimensioned matrices (plus, there are so many reasonable matrix “subtypes” that there's no guarantee that the return type should always be the same), and I don’t think there’s a generally agreed-upon meaning for matrix division at all.

There’s a natural tension of exactly what structure in the hierarchy of semigroups, groups, rings, etc is the baseline to be “numbery”.  While it’s not totally obvious that division should be required, neither is it obvious that it should be excluded.

I should note that for non-scalar types, multiplication and division are frequently more reasonable than addition and subtraction.  E.g. the orthogonal matrix groups and unitary quaternions are closed under multiplication but not addition.

Ultimately, we may want to have a finer-grained classification of numeric protocols, but “schoolbook arithmetic” is a pretty reasonable set of operations while we’re picking just one.

– Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160415/b5287cf5/attachment.html>