<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div><blockquote type="cite" class=""><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><br class=""></div>I don't think this solves the precision issue. It makes it harder to use fmod, but doesn't stop people wanting to, life finds a way. I completely agree with your rationale, but if someone wants mod they'll use mod. The question probably comes down to whether stackoverflow will tell them to use fmod or remainder.<br class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div></div></div></blockquote>As someone who does mostly numerical programming, I’m okay with the proposed change. I do agree with Andrew,&nbsp;however, that it is unlikely to have much of an effect on whether the floating point modulus operation is used in an&nbsp;enlightened way.<br class=""><br class="">There’s always hope, though, and drawing a clear distinction between the integer and floating point operations seems&nbsp;appropriate in light of the aspirations for Swift to be a teaching language.<br class=""><br class="">I have mixed feelings at best about having instance methods for fmod() and remainder(), though. The draft Swift API design&nbsp;guidelines suggest preferring methods and properties except “when function syntax is part of the established domain&nbsp;notation”. The use of freestanding functions for mathematical operations is well established in other programming&nbsp;languages, and I think it generally is a better match to mathematical notation (i.e., more equation-like).<br class=""><br class="">I’m strongly against adding an identically named mod() for integers. Having the same method for integers and floats is just&nbsp;reintroducing the original problem by making the two operations seem equivalent.</div><div class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 19, 2015 at 12:10 PM, Joe Groff via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 3:40 PM, August Joki via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""><br class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">-August</span></div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" class=""><div class="">On 18 Dec, 2015, at 15:31, Kevin Ballard via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class=""><div class=""><div class=""><div class="">On Fri, Dec 18, 2015, at 03:04 PM, Chris Lattner via swift-evolution wrote:<br class=""></div><blockquote type="cite" class=""><div class="">&nbsp;</div><div class=""><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 3:03 PM, Stephen Canon &lt;<a href="mailto:scanon@apple.com" target="_blank" class="">scanon@apple.com</a>&gt; wrote:<br class=""></div><div class="">&nbsp;</div><div class=""><div style="word-wrap:break-word" class=""><div class="">&nbsp;</div><div class=""><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 5:57 PM, Chris Lattner &lt;<a href="mailto:clattner@apple.com" target="_blank" class="">clattner@apple.com</a>&gt; wrote:<br class=""></div><div class="">&nbsp;</div><div class=""><div style="word-wrap:break-word" class=""><div class="">On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">Hi everybody —<br class=""></div><div class="">&nbsp;</div><div class="">I’d like to propose removing the “%” operator for floating-point types.<br class=""></div></div></div></blockquote><div class="">&nbsp;</div><div class="">I support removing this - it is actively harmful for a surprising operation like this to have such short and inviting syntax.&nbsp; As asked downthread, have you given any thought into whether a Decimal type would support this operation?<br class=""></div></div></div></div></blockquote><div class="">&nbsp;</div></div><div class="">The same concerns apply to decimal.&nbsp; It makes sense to have the operation (for both binary and decimal floating-point) as “Type.remainder(a,b)” or a free function like "remainder(a, b)”, but I would prefer not to use the operator “%” for it because it behaves very differently from integer %, and in ways that are not at all obvious to most users.<br class=""></div></div></div></blockquote><div class="">&nbsp;</div></div><div class="">Great, I’d prefer decimal and the float types to have a consistent interface where possible. &nbsp;+1 from me on the proposal.<br class=""></div></blockquote><div class="">&nbsp;</div><div class="">Agreed. +1 from me too. The `10.0 % 0.1` behavior is sufficiently surprising that I think that justifies removal by itself.<br class=""></div><div class="">&nbsp;</div><div class="">I'm also in favor of adding mod and remainder as instance methods of the floating point types, e.g. `10.0.mod(0.1)` (as opposed to static methods or free functions).<br class=""></div></div></div></blockquote>Shouldn’t that be added to any Arithmetic type?<br class=""></div></div></blockquote><div class=""><br class=""></div></span>We don't offer protocols that abstract over both integer and float arithmetic. They behave differently, and require different algorithms and interfaces. Floating-point types gaining a `mod` member does not necessarily mean integer types should get the same.</div><div class=""><br class=""></div><div class="">-Joe<br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uQFKl6aWB0uo7-2F8NFAb-2FCKKagd5iBYeIW8W0NTTsT7sGtChiYyyvZ9TFMYMc1kY0HZUQ4rk7pgPuQZ-2BPBTo7rW-2BtvhHhaQe2uHUBHtwiMVRfc29f-2FWRfUS71QRY19NHeTWPX27HW3vyBdaYUfICS7Jm3S5iPOFNt49m1rV98JD8D-2BEngycR4QRsyhTKrZ7JYF8-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important" class="">
</div>
<br class=""></blockquote></div></div></div></div></div></blockquote></div><br class=""></div></body></html>