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/62ffe3c91b66866fdebf6f >> 3fcc7cad8c ] >> >> >> 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 >> <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?
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution