> On Jan 15, 2017, at 17:19, Jacob Bandes-Storch via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>> On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>
>>> [ proposal link:
>>> https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f3fcc7cad8c ]
>>>
>>>
>>>> On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> Responding to both Jacob and Xiaodi here; thanks very much for your
>>>> feedback!
>>>>
>>>> on Sat Jan 14 2017, Xiaodi Wu <swift-evolution@swift.org> wrote:
>>>> > I think, in the end, it's the _name_ that could use improvement here. As
>>>> > the doc comments say, `Arithmetic` is supposed to provide a "suitable
>>>> > basis
>>>> > for arithmetic on scalars"--perhaps `ScalarArithmetic` might be more
>>>> > appropriate? It would make it clear that `CGVector` is not meant to be a
>>>> > conforming type.
>>>>
>>>> We want Arithmetic to be able to handle complex numbers. Whether Scalar
>>>> would be appropriate in that case sort of depends on what the implied
>>>> field is, right?
>>>
>>> I think "scalar" is an appropriate term for any field. The scalar-ness
>>> usually comes into play when it's used in a vector space, but using the
>>> term alone doesn't bother me.
>>>
>>>> It's true that CGPoint and CGVector have no obvious sensible
>>>> interpretation of "42", and that's unfortunate. The problem with
>>>> protocols for algebraic structures is that there's an incredibly
>>>> complicated lattice (see figures 3.1, 3.2 in
>>>> ftp://jcmc.indiana.edu/pub/techreports/TR638.pdf) and we don't want to
>>>> shove all of those protocols into the standard library (especially not
>>>> prematurely) but each requirement you add to a more-coarsely aggregated
>>>> protocol like Arithmetic will make it ineligible for representing some
>>>> important type.
>>>
>>> Yep, it is quite complicated, and I understand not wanting to address all
>>> that right now; calling it ScalarArithmetic seems appropriate to clarify
>>> the limitations. FieldArithmetic might also be appropriate, but is less
>>> clear (+ see below about quaternions).
>>>
>>> Daves Sweeris and Abrahams wrote:
>>>
>>> > > I was under the impression that complex numbers are scalar numbers...
>>> > > although maybe not since once you get past, I think quaternions, you
>>> > > start losing division and eventually multiplication, IIRC. (I hate it
>>> > > when two of my recollections try to conflict with each other.)
>>> >
>>> > Well, you can view them as 2d vectors, so I'm not sure. We need more of
>>> > a numerics expert than I am to weigh in here.
>>>
>>> But complex numbers have multiplication and division operations defined
>>> (they form a field), unlike regular vectors in R². Meaning you can have a
>>> vector space over the field of complex numbers.
>>>
>>> You still have multiplication and division past quaternions, but the
>>> quaternions are not commutative. This isn't really a problem in Swift,
>>> since the compiler never allows you to write an expression where the order
>>> of arguments to an operator is ambiguous. This means they are not a field,
>>> just a division ring (a field is a commutative division ring). (I believe
>>> you can't technically have a vector space over a non-commutative ring; the
>>> generalization would be a module. That's probably an argument for the name
>>> ScalarArithmetic over FieldArithmetic.)
>>
>> Hmm, the issue is that the integers are not a field. So, if we're going to
>> have it all modeled by one protocol, maybe neither is the best term.
>
> Eurgh. That's true. Appropriate mathematical terms go out the window when
> "division" doesn't actually produce a multiplicative inverse.
>
> BasicArithmetic?
I was thinking something similar... Could we just rename Int/UInt to
Counter/UnsignedCounter, and leave all these "mathematically correct" protocols
and types to mathematically correct numeric libraries?
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
