<div dir="ltr">On Mon, Jan 16, 2017 at 12:44 AM, 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><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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> Responding to the thread in general here, not so much any specific email:<br>
><br>
> “Arithmetic” at present is not a mathematically-precise concept, and<br>
> it may be a mistake to make it be one[1]; it’s a<br>
> mathematically-slightly-fuzzy “number” protocol. FWIW, if I had to<br>
> pick a mathematical object to pin it to, I would make it a<br>
> [non-commutative] ring, which give it:<br>
><br>
> addition, subtraction, multiplication, IntegerLiteralConvertible, and an inverse: T?<br>
> property.<br>
><br>
> Note that this would make division go out the window, but we would<br>
> *preserve* int literal convertible (because there’s a unique map from<br>
> Z to any ring — Z is the initial object in the category of rings). I<br>
> think that it’s quite important to keep that for writing generic code.<br>
><br>
> Vectors and points are not “numbery” in this sense, so they should not<br>
> conform to this protocol, which is why it’s OK that multiplication and<br>
> int literals don’t make sense for them. They’re property a vector<br>
> space or module built over a scalar type.<br>
><br>
> I would be OK with moving division out of the Arithmetic protocol, as<br>
> the division operator is fundamentally different for integers and<br>
> floating-point, and you want to have separate left- and right-<br>
> division for quaternions and matrices. I would be pretty strongly<br>
> opposed to removing integer literals; they rightfully belong here.<br>
><br>
> I think the name “Arithmetic” is sound. It is deliberately *not* one<br>
> of the standard mathematical abstractions, reserving those names for<br>
> folks who want to build a precise lattice of algebraic<br>
> 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'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="">
> – Steve<br>
><br>
> [1] We don’t want to make a semester course in modern algebra a<br>
> prerequisite to using Swift, as much as I would enjoy building a tower<br>
> 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>