[swift-evolution] protocol-oriented integers (take 2)

[Jacob Bandes-Storch]

On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> [ proposal link: https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f
>> 3fcc7cad8c ]
>>
>>
>> On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution <
>> swift-evolution at 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 at 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
>> <https://en.wikipedia.org/wiki/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
>> <https://en.wikipedia.org/wiki/Module_%28mathematics%29>. 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170115/eed57153/attachment.html>