> On Apr 14, 2016, at 10:47 PM, [email protected] 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
>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
