<div dir="ltr">On Mon, Jan 16, 2017 at 12:44 AM, Dave Abrahams via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
on Sun Jan 15 2017, Stephen Canon &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; Responding to the thread in general here, not so much any specific email:<br>
&gt;<br>
&gt; “Arithmetic” at present is not a mathematically-precise concept, and<br>
&gt; it may be a mistake to make it be one[1]; it’s a<br>
&gt; mathematically-slightly-fuzzy “number” protocol. FWIW, if I had to<br>
&gt; pick a mathematical object to pin it to, I would make it a<br>
&gt; [non-commutative] ring, which give it:<br>
&gt;<br>
&gt;       addition, subtraction, multiplication, IntegerLiteralConvertible, and an inverse: T?<br>
&gt;       property.<br>
&gt;<br>
&gt; Note that this would make division go out the window, but we would<br>
&gt; *preserve* int literal convertible (because there’s a unique map from<br>
&gt; Z to any ring — Z is the initial object in the category of rings). I<br>
&gt; think that it’s quite important to keep that for writing generic code.<br>
&gt;<br>
&gt; Vectors and points are not “numbery” in this sense, so they should not<br>
&gt; conform to this protocol, which is why it’s OK that multiplication and<br>
&gt; int literals don’t make sense for them. They’re property a vector<br>
&gt; space or module built over a scalar type.<br>
&gt;<br>
&gt; I would be OK with moving division out of the Arithmetic protocol, as<br>
&gt; the division operator is fundamentally different for integers and<br>
&gt; floating-point, and you want to have separate left- and right-<br>
&gt; division for quaternions and matrices. I would be pretty strongly<br>
&gt; opposed to removing integer literals; they rightfully belong here.<br>
&gt;<br>
&gt; I think the name “Arithmetic” is sound. It is deliberately *not* one<br>
&gt; of the standard mathematical abstractions, reserving those names for<br>
&gt; folks who want to build a precise lattice of algebraic<br>
&gt; objects. Vectors don’t belong in this protocol, though.<br>
<br>
</div></div>OK, suppose we move division, and state in the documentation that models<br>
of Arithmetic should have the mathematical properties of a<br>
(non-commutative) Ring?<br></blockquote><div><br></div><div>Unless I&#39;m mistaken, after removing division, models of SignedArithmetic would have the mathematical properties of a ring. For every element a in ring R, there must exist an additive inverse -a in R such that a + (-a) = 0. Models of Arithmetic alone would not necessarily have that property.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt; – Steve<br>
&gt;<br>
&gt; [1] We don’t want to make a semester course in modern algebra a<br>
&gt; prerequisite to using Swift, as much as I would enjoy building a tower<br>
&gt; of formalism as a mathematician.<br>
<br>
</span>Indeedy.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
-Dave<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div>