<div>One example: earlier, it was demonstrated that a genetic lerp would not accommodate vector types. However, it _does_ work fine for any scalar (i.e. field) type; however, with the currently proposed integer protocols, one would constrain it to Arithmetic types, yet the algorithm would be bogus for integers.</div><div><br></div><div><br><div class="gmail_quote"><div>On Sun, Jan 15, 2017 at 19:21 Dave Abrahams &lt;<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg"><br>on Sun Jan 15 2017, Xiaodi Wu &lt;<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" class="gmail_msg" target="_blank">xiaodi.wu-AT-gmail.com</a>&gt; wrote:<br class="gmail_msg"><br><br class="gmail_msg"><br>&gt; On Sun, Jan 15, 2017 at 3:27 PM, Dave Abrahams via swift-evolution &lt;<br class="gmail_msg"><br>&gt; <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; on Sun Jan 15 2017, Xiaodi Wu &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; &gt; There _may_ be value in recognizing the distinction between rings and<br class="gmail_msg"><br>&gt;&gt; &gt; fields, perhaps? Just as the FP protocols make room for people to<br class="gmail_msg"><br>&gt;&gt; implement<br class="gmail_msg"><br>&gt;&gt; &gt; their own decimal FP types, and just as you&#39;re trying to make Arithmetic<br class="gmail_msg"><br>&gt;&gt; &gt; accommodate complex numbers, the distinction would allow someone to write<br class="gmail_msg"><br>&gt;&gt; &gt; algorithms generic over rationals and reals (i.e. fields). Being able to<br class="gmail_msg"><br>&gt;&gt; &gt; represent exact fractions isn&#39;t so terribly niche, and I think the design<br class="gmail_msg"><br>&gt;&gt; &gt; wouldn&#39;t be terribly complicated by its accommodation:<br class="gmail_msg"><br>&gt;&gt; &gt;<br class="gmail_msg"><br>&gt;&gt; &gt; ```<br class="gmail_msg"><br>&gt;&gt; &gt; // rename Arithmetic to Ring<br class="gmail_msg"><br>&gt;&gt; &gt; // it&#39;s acceptable to omit `.one` from Ring, though some may call that a<br class="gmail_msg"><br>&gt;&gt; &gt; Pseudoring<br class="gmail_msg"><br>&gt;&gt; &gt; // consider omitting division from Ring and pushing it down to<br class="gmail_msg"><br>&gt;&gt; &gt; BinaryInteger and Field<br class="gmail_msg"><br>&gt;&gt; &gt;<br class="gmail_msg"><br>&gt;&gt; &gt; protocol BinaryInteger : Ring { ... }<br class="gmail_msg"><br>&gt;&gt; &gt;<br class="gmail_msg"><br>&gt;&gt; &gt; protocol Field : Ring {<br class="gmail_msg"><br>&gt;&gt; &gt;   static var one { get }<br class="gmail_msg"><br>&gt;&gt; &gt;   static func / (Self, Self) -&gt; Self<br class="gmail_msg"><br>&gt;&gt; &gt;   static func /= (inout Self, Self)<br class="gmail_msg"><br>&gt;&gt; &gt;   var inverted: Self { get } // default impl: .one / self<br class="gmail_msg"><br>&gt;&gt; &gt; }<br class="gmail_msg"><br>&gt;&gt; &gt;<br class="gmail_msg"><br>&gt;&gt; &gt; protocol FloatingPoint : Field { ... }<br class="gmail_msg"><br>&gt;&gt; &gt; // rational number types and complex number types<br class="gmail_msg"><br>&gt;&gt; &gt; // would also conform to Field<br class="gmail_msg"><br>&gt;&gt; &gt; ```<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;&gt; What generic algorithms would this enable?<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt; For one, anything to do with dividing into equal parts<br class="gmail_msg"><br><br class="gmail_msg"><br>For example...?<br class="gmail_msg"><br><br class="gmail_msg"><br>&gt; could be generic over floating point, rational, and even complex<br class="gmail_msg"><br>&gt; numbers, but you probably wouldn&#39;t want to include integer types in<br class="gmail_msg"><br>&gt; such an algorithm.<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt;&gt; Would they be appropriate<br class="gmail_msg"><br>&gt;&gt; for the standard library (as opposed to some more specialized numerics<br class="gmail_msg"><br>&gt;&gt; library)?<br class="gmail_msg"><br>&gt;&gt;<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt; The issue is that it&#39;s not terribly ergonomic to relegate `Field` to a<br class="gmail_msg"><br>&gt; specialized library because one cannot retroactively conform<br class="gmail_msg"><br>&gt; `FloatingPoint` to `Field`.<br class="gmail_msg"><br><br class="gmail_msg"><br>I don&#39;t think this is an important enough concern to justify adding<br class="gmail_msg"><br>protocols to the standard library.  The number of types one has to<br class="gmail_msg"><br>individually make conform to Field is probably going to remain small.<br class="gmail_msg"><br><br class="gmail_msg"><br>Show-me-the-mone^Walgorithms-ly y&#39;rs,<br class="gmail_msg"><br><br class="gmail_msg"><br>--<br class="gmail_msg"><br>-Dave<br class="gmail_msg"><br></blockquote></div></div>