<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 <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>> 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 <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" class="gmail_msg" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br class="gmail_msg"><br><br class="gmail_msg"><br>> On Sun, Jan 15, 2017 at 3:27 PM, Dave Abrahams via swift-evolution <<br class="gmail_msg"><br>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br>><br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> on Sun Jan 15 2017, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> > There _may_ be value in recognizing the distinction between rings and<br class="gmail_msg"><br>>> > fields, perhaps? Just as the FP protocols make room for people to<br class="gmail_msg"><br>>> implement<br class="gmail_msg"><br>>> > their own decimal FP types, and just as you're trying to make Arithmetic<br class="gmail_msg"><br>>> > accommodate complex numbers, the distinction would allow someone to write<br class="gmail_msg"><br>>> > algorithms generic over rationals and reals (i.e. fields). Being able to<br class="gmail_msg"><br>>> > represent exact fractions isn't so terribly niche, and I think the design<br class="gmail_msg"><br>>> > wouldn't be terribly complicated by its accommodation:<br class="gmail_msg"><br>>> ><br class="gmail_msg"><br>>> > ```<br class="gmail_msg"><br>>> > // rename Arithmetic to Ring<br class="gmail_msg"><br>>> > // it's acceptable to omit `.one` from Ring, though some may call that a<br class="gmail_msg"><br>>> > Pseudoring<br class="gmail_msg"><br>>> > // consider omitting division from Ring and pushing it down to<br class="gmail_msg"><br>>> > BinaryInteger and Field<br class="gmail_msg"><br>>> ><br class="gmail_msg"><br>>> > protocol BinaryInteger : Ring { ... }<br class="gmail_msg"><br>>> ><br class="gmail_msg"><br>>> > protocol Field : Ring {<br class="gmail_msg"><br>>> > static var one { get }<br class="gmail_msg"><br>>> > static func / (Self, Self) -> Self<br class="gmail_msg"><br>>> > static func /= (inout Self, Self)<br class="gmail_msg"><br>>> > var inverted: Self { get } // default impl: .one / self<br class="gmail_msg"><br>>> > }<br class="gmail_msg"><br>>> ><br class="gmail_msg"><br>>> > protocol FloatingPoint : Field { ... }<br class="gmail_msg"><br>>> > // rational number types and complex number types<br class="gmail_msg"><br>>> > // would also conform to Field<br class="gmail_msg"><br>>> > ```<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> What generic algorithms would this enable?<br class="gmail_msg"><br>><br class="gmail_msg"><br>> 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>> could be generic over floating point, rational, and even complex<br class="gmail_msg"><br>> numbers, but you probably wouldn't want to include integer types in<br class="gmail_msg"><br>> such an algorithm.<br class="gmail_msg"><br>><br class="gmail_msg"><br>>> Would they be appropriate<br class="gmail_msg"><br>>> for the standard library (as opposed to some more specialized numerics<br class="gmail_msg"><br>>> library)?<br class="gmail_msg"><br>>><br class="gmail_msg"><br>><br class="gmail_msg"><br>> The issue is that it's not terribly ergonomic to relegate `Field` to a<br class="gmail_msg"><br>> specialized library because one cannot retroactively conform<br class="gmail_msg"><br>> `FloatingPoint` to `Field`.<br class="gmail_msg"><br><br class="gmail_msg"><br>I don'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'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>