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