<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>It occurs to me that we already have precedent for a Swift global function (not operator) that implements a mathematic operation, and that is abs(). There is an AbsoluteValuable protocol that offers a static abs() method that can be used to override the default implementation (which is comparing the value against zero and negating it), but the intended usage is always to invoke the global function.<br></div>
<div> </div>
<div>That said, I wouldn't be opposed to changing this around so abs() is a method of SignedNumberType (and AbsoluteValuable would go away entirely, since types that conform to SignedNumberType can just override the method).<br></div>
<div> </div>
<div>I also think there's a slight difference between "basic" functions like abs() and mod() (things that are useful in non-mathematical code) versus more general "math-y" functions like sin(). But I don't have strong feelings on this; as you say, the draft guidelines do say to use functions when function syntax is the established domain notation.<br></div>
<div> </div>
<div>-Kevin Ballard</div>
<div> </div>
<div>On Sat, Dec 19, 2015, at 04:47 PM, Charles Kissinger via swift-evolution wrote:<br></div>
<blockquote type="cite"><div><div><blockquote type="cite"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;"> </div>
<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></div>
<div dir="ltr"><div><div> </div>
</div>
</div>
</blockquote><div>As someone who does mostly numerical programming, I’m okay with the proposed change. I do agree with Andrew, however, that it is unlikely to have much of an effect on whether the floating point modulus operation is used in an enlightened way.<br></div>
<div> </div>
<div>There’s always hope, though, and drawing a clear distinction between the integer and floating point operations seems appropriate in light of the aspirations for Swift to be a teaching language.<br></div>
<div> </div>
<div>I have mixed feelings at best about having instance methods for fmod() and remainder(), though. The draft Swift API design guidelines suggest preferring methods and properties except “when function syntax is part of the established domain notation”. The use of freestanding functions for mathematical operations is well established in other programming languages, and I think it generally is a better match to mathematical notation (i.e., more equation-like).<br></div>
<div> </div>
<div>I’m strongly against adding an identically named mod() for integers. Having the same method for integers and floats is just reintroducing the original problem by making the two operations seem equivalent.<br></div>
</div>
<div><div> </div>
<blockquote type="cite"><div dir="ltr"><div><div><div><div><div>On Sat, Dec 19, 2015 at 12:10 PM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>></span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;"><div style="word-wrap:break-word;"><div> </div>
<div><div> </div>
<blockquote type="cite"><div><span>On Dec 18, 2015, at 3:40 PM, August Joki via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></div>
<div> </div>
<div><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;"><span><br><br><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">-August</span></span></span></div>
<div><span><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;"></span></div>
<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;"><blockquote type="cite"><div><span>On 18 Dec, 2015, at 15:31, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></div>
<div> </div>
<div><div><div><span>On Fri, Dec 18, 2015, at 03:04 PM, Chris Lattner via swift-evolution wrote:</span><br></div>
<blockquote type="cite"><div> </div>
<div><blockquote type="cite"><div><span>On Dec 18, 2015, at 3:03 PM, Stephen Canon <<a href="mailto:scanon@apple.com">scanon@apple.com</a>> wrote:</span><br></div>
<div> </div>
<div><div style="word-wrap:break-word;"><div> </div>
<div><blockquote type="cite"><div><span>On Dec 18, 2015, at 5:57 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:</span><br></div>
<div> </div>
<div><div style="word-wrap:break-word;"><div><span>On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></div>
<div><blockquote type="cite"><div><div style="word-wrap:break-word;"><div><span>Hi everybody —</span><br></div>
<div> </div>
<div><span>I’d like to propose removing the “%” operator for floating-point types.</span><br></div>
</div>
</div>
</blockquote><div> </div>
<div><span>I support removing this - it is actively harmful for a surprising operation like this to have such short and inviting syntax. As asked downthread, have you given any thought into whether a Decimal type would support this operation?</span><br></div>
</div>
</div>
</div>
</blockquote><div> </div>
</div>
<div><span>The same concerns apply to decimal. 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.</span><br></div>
</div>
</div>
</blockquote><div> </div>
</div>
<div><span>Great, I’d prefer decimal and the float types to have a consistent interface where possible. +1 from me on the proposal.</span><br></div>
</blockquote><div> </div>
<div><span>Agreed. +1 from me too. The `10.0 % 0.1` behavior is sufficiently surprising that I think that justifies removal by itself.</span><br></div>
<div> </div>
<div><span>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).</span><br></div>
</div>
</div>
</blockquote><div><span>Shouldn’t that be added to any Arithmetic type?</span><br></div>
</div>
</div>
</blockquote><div> </div>
<div><span></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.<br></div>
</div>
<div> </div>
<div>-Joe<br></div>
<div><img style="min-height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/3b08b646e73f923514b7baa4daa1c02bf72a8c2d7f16e34a33e74219a486053a/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d30715777386833366754733c4c42676b666c443453555c403775616a5e66564a5874456537435867743571564b4c6631675240357f673d2236483e4641426d2236434b4b416764653962495569475837503e4454537457337744734869695979767a5934564d495d43613b6950384a555154327b6730776055715a5d22324052445f6732775d223244767868486161556235784552484477796d465256636239366d22364752566553573131525951393e48456457505852373847533679724461695556694343573a4d63335539605f464e4474393d61327659383a4448344d2232454e67697362543152537978645b427a573a4956483d23344/open"><br></div>
</div>
</blockquote></div>
</div>
</div>
</div>
</div>
</blockquote></div>
</div>
<div><img style="height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/4ad0b844a1559addc1c8c89b8c0e33d26238caf19ca905e9242e33096d10e779/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d3148765176786c673171614a7d2236454230345272776e4853373d2232467879553957305372413b4f405935514658513f6a4d69734263485249394a476641637a40786739674753476a6b416e61484a7f63413f4167594679436376386d627b65424d47787671444e414a7d65703b656d2236434d22324d2232424354565732405c496b4d40344270393831716335645b405d62714d6939754b4545656662426d6346333f4965384979555457473e607260553a585a733d22364970527832767746796464416863353c65705e6c4134785952336e6f42364267415d22324537537671514d23344d23344/open"><br></div>
<div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote><div> </div>
</body>
</html>