<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Jan 15, 2017, at 17:19, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div><div class="m_4597847822642383667gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div></div></div></div><div class="gmail_quote">On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="m_4597847822642383667h5">On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_4597847822642383667h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">[ proposal link: <a href="https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f3fcc7cad8c" target="_blank">https://gist.github.com/<wbr>moiseev/62ffe3c91b66866fdebf6f<wbr>3fcc7cad8c</a> ]<br><div class="gmail_extra"><div><div class="m_4597847822642383667m_-2683530120925045933m_5460228561171012455m_-7385509867756785065gmail_signature"><div dir="ltr"><div><br></div></div></div></div>
<br><div class="gmail_quote"><span>On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
Responding to both Jacob and Xiaodi here; thanks very much for your<br>
feedback!<br>
<span class="m_4597847822642383667m_-2683530120925045933m_5460228561171012455m_-7385509867756785065gmail-"><br>
on Sat Jan 14 2017, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</span></span><span><span class="m_4597847822642383667m_-2683530120925045933m_5460228561171012455m_-7385509867756785065gmail-"><br>
> I think, in the end, it's the _name_ that could use improvement here. As<br>
> the doc comments say, `Arithmetic` is supposed to provide a "suitable basis<br>
> for arithmetic on scalars"--perhaps `ScalarArithmetic` might be more<br>
> appropriate? It would make it clear that `CGVector` is not meant to be a<br>
> conforming type.<br>
<br>
</span>We want Arithmetic to be able to handle complex numbers. Whether Scalar<br>
would be appropriate in that case sort of depends on what the implied<br>
field is, right?<br></span></blockquote><div><br></div><div>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.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's true that CGPoint and CGVector have no obvious sensible<br>
interpretation of "42", and that's unfortunate. The problem with<br>
protocols for algebraic structures is that there's an incredibly<br>
complicated lattice (see figures 3.1, 3.2 in<br>
<a href="ftp://jcmc.indiana.edu/pub/techreports/TR638.pdf" rel="noreferrer" target="_blank">ftp://jcmc.indiana.edu/pub/tec<wbr>hreports/TR638.pdf</a>) and we don't want to<br>
shove all of those protocols into the standard library (especially not<br>
prematurely) but each requirement you add to a more-coarsely aggregated<br>
protocol like Arithmetic will make it ineligible for representing some<br>
important type.<br></blockquote><div><br></div></span><div>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).</div><div><br></div><div>Daves Sweeris and Abrahams wrote:</div><div><br></div><div>> > 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.) </div><span><div>></div><div>> 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.</div><div> </div></span><div>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.</div><div><br></div><div>You still have multiplication and division past quaternions, but the quaternions are <b>not commutative</b>. 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 <b>not a field</b>, just a <a href="https://en.wikipedia.org/wiki/Division_ring" target="_blank">division ring</a> (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 <a href="https://en.wikipedia.org/wiki/Module_%28mathematics%29" target="_blank">module</a>. That's probably an argument for the name ScalarArithmetic over FieldArithmetic.)</div></div></div></div></blockquote><div><br></div></div></div><div>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.</div></div></div></div></blockquote><div><br></div><div>Eurgh. That's true. Appropriate mathematical terms go out the window when "division" doesn't actually produce a multiplicative inverse.</div><div><br></div><div>BasicArithmetic?</div></div></div></div></div></blockquote><br><div>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?</div><div><br></div><div>- Dave Sweeris</div></body></html>