<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div>On Sat, May 7, 2016 at 6:44 PM, Miller Puckette <span dir="ltr"><<a href="mailto:msp@ucsd.edu" target="_blank">msp@ucsd.edu</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>I _think_ (but am not sure) that "%" works differently on different<br>CPU architectures.</div></blockquote></div></div></blockquote><div> </div></div><div class="gmail_quote">2016-05-07 20:20 GMT-03:00 Matt Barber <span dir="ltr"><<a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:verdana,sans-serif">​% can be different with respect to sign in different implementations of C. fmod() in C is designed to work with floats.</div></div></blockquote><div><br></div><div>Wow, so using "%" in a source code can generate different results in <span style="color:rgb(80,0,80)">different </span><span style="color:rgb(80,0,80)">CPU architectures?</span></div><div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)">that's interesting... Can we confirm that? And, if so, why?</span></div><div><br></div><div>And how about fmod? Sames as %? By the way, the [%~] (or [modulo~] object - also present in cyclone - uses "fmod". And "fmod" in expr family also uses fmod...</div><div><br></div><div>But anyway [%], [mod] and "%" in [expr] use the "%" operation in the C code...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:verdana,sans-serif">On my system, -10 [mod 3] and -10 [% 3] in Pd work differently. [mod] outputs the positive remainder, which is 2, while % outputs the remainder with the sign of the dividend, which is -1.<br></div></div></blockquote><div><br></div><div>I also get that, and I'm on a mac intel... and this behaviour with the [%] object is what you get if you are using a code in C with "fmod"... (%~ and "fmod" in expr). </div><div><br></div><div><div>And well, looking at the source code in x_arithmetic.c, both % and mod rely on the "%" operation in the C code, but [mod] turns the input negative values into positive input values</div><div><br></div><div>"<span>if</span><span> (n2 < </span><span>0</span><span>) n2 = -n2;"</span></div></div><div><span><br></span></div><div><span>[%] and [expr $f1 % $f2] use "%" in the C code without turning negative input to positive input, so the results are the same. I'm getting the same behaviour as Matt, but if there's this deal with different results depending on architecture, then % in [expr] is subject to the same effect.</span></div><div><span><br></span></div><div><span>But anyway, again, </span>comparing to others in Pd and Max, it seems like the [mod] object is the odd one out, where it converts negative input to positive input on purpose. Lets say it has this behaviour intentionally, but also that we could keep [%] with this other intentional behaviour.<br></div><div><br></div><div>If the way things are coded makes it undefined or dependent on CPU architecture, then it's a bug and we could force it to behave always in the way where <span style="font-family:verdana,sans-serif">-10 [% 3] gives "-1".</span></div><div><span style="font-family:verdana,sans-serif"><br></span></div><div><span style="font-family:verdana,sans-serif">cheers</span></div></div></div></div>