<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br><div>Sent from my moss-covered three-handled family gradunza</div></div><div><br>On Jan 15, 2017, at 6:46 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com">jtbandes@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div><div class="m_-3404327379327894526gmail_signature"><div dir="ltr"><div>On Sun, Jan 15, 2017 at 6:13 PM, Xiaodi Wu via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></blockquote><div><br></div><div>I wouldn't say lerp<Int> is bogus (the results aren't wrong), just much less useful.</div><div><br></div><div>On the other hand:</div><div><br></div><div><font face="monospace, monospace"> extension Collection where Iterator.Element: Arithmetic {</font></div><div><font face="monospace, monospace"> func mean() -> Iterator.Element {</font></div><div><font face="monospace, monospace"> return self.reduce(Iterator.Element()<wbr>, +) / Iterator.Element(count) // assuming these initializers exist</font></div><div><font face="monospace, monospace"> }</font></div><div><font face="monospace, monospace"> }</font></div><div> </div><div>Now [6, 7].mean() returns 6, and <b>that</b> I would call bogus.</div><div><br></div><div>Of course, there are some alternative ways to implement this which avoid the issue:</div><div><br></div><div>- Implement it only for Iterator.Element: FloatingPoint.</div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>- Implement it as mean<T: FloatingPoint>() -> T, reducing by { $0 + T($1) } or whatever the appropriate conversion initializer is, or simply converting to floating point once <i>after</i> taking the sum.</div></div></div></div></div></blockquote><div><br></div><div>You really want this to work for any field, though. Rational numbers, for example, would be excluded by those constraints</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_-3404327379327894526gmail-HOEnZb"><div class="m_-3404327379327894526gmail-h5"><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" target="_blank">dabrahams@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>on Sun Jan 15 2017, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>> On Sun, Jan 15, 2017 at 3:27 PM, Dave Abrahams via swift-evolution <<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>> <a href="mailto:swift-evolution@swift.org" class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> on Sun Jan 15 2017, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org" class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > There _may_ be value in recognizing the distinction between rings and<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > fields, perhaps? Just as the FP protocols make room for people to<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> implement<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > their own decimal FP types, and just as you're trying to make Arithmetic<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > accommodate complex numbers, the distinction would allow someone to write<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > algorithms generic over rationals and reals (i.e. fields). Being able to<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > represent exact fractions isn't so terribly niche, and I think the design<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > wouldn't be terribly complicated by its accommodation:<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> ><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > ```<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > // rename Arithmetic to Ring<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > // it's acceptable to omit `.one` from Ring, though some may call that a<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > Pseudoring<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > // consider omitting division from Ring and pushing it down to<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > BinaryInteger and Field<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> ><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > protocol BinaryInteger : Ring { ... }<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> ><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > protocol Field : Ring {<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > static var one { get }<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > static func / (Self, Self) -> Self<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > static func /= (inout Self, Self)<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > var inverted: Self { get } // default impl: .one / self<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > }<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> ><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > protocol FloatingPoint : Field { ... }<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > // rational number types and complex number types<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > // would also conform to Field<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> > ```<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> What generic algorithms would this enable?<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>> For one, anything to do with dividing into equal parts<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>For example...?<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>> could be generic over floating point, rational, and even complex<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>> numbers, but you probably wouldn't want to include integer types in<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>> such an algorithm.<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> Would they be appropriate<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> for the standard library (as opposed to some more specialized numerics<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>> library)?<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>>><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>> The issue is that it's not terribly ergonomic to relegate `Field` to a<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>> specialized library because one cannot retroactively conform<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>> `FloatingPoint` to `Field`.<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>I don't think this is an important enough concern to justify adding<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>protocols to the standard library. The number of types one has to<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>individually make conform to Field is probably going to remain small.<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>Show-me-the-mone^Walgorithms-l<wbr>y y'rs,<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br><br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>--<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br>-Dave<br class="m_-3404327379327894526gmail-m_-925663533859349757gmail_msg"><br></blockquote></div></div>
</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote></body></html>