fmod() is a c function with a consistent definition: http://en.cppreference.com/w/c/numeric/math/fmod
If I remember correctly, the % operator result can take the sign of its dividend, but it does not have to; it is implementation specific. Likewise integer division using / is implementation specific (truncation vs. flooring), but I believe it is guaranteed to be consistent with %. Hence the rationale for div(). On Sun, May 8, 2016 at 12:09 AM, Alexandre Torres Porres <por...@gmail.com> wrote: > cool, yeah, i fugured there was a reason for mod to be coded the way it is > > but I'm more concerned on how "%" could be unreliable... or even "fmod"? > > cheers > > 2016-05-08 1:01 GMT-03:00 Jonathan Wilkes <jancs...@yahoo.com>: > >> >> http://article.gmane.org/gmane.comp.multimedia.puredata.general/56291/match=div+mod >> >> >> On Saturday, May 7, 2016 11:45 PM, Alexandre Torres Porres < >> por...@gmail.com> wrote: >> >> >> On Sat, May 7, 2016 at 6:44 PM, Miller Puckette <m...@ucsd.edu> wrote: >> >> I _think_ (but am not sure) that "%" works differently on different >> CPU architectures. >> >> >> 2016-05-07 20:20 GMT-03:00 Matt Barber <brbrof...@gmail.com>: >> >> % can be different with respect to sign in different implementations of >> C. fmod() in C is designed to work with floats. >> >> >> Wow, so using "%" in a source code can generate different results in >> different CPU architectures? >> >> that's interesting... Can we confirm that? And, if so, why? >> >> 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... >> >> But anyway [%], [mod] and "%" in [expr] use the "%" operation in the C >> code... >> >> 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. >> >> >> 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). >> >> 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 >> >> "if (n2 < 0) n2 = -n2;" >> >> [%] 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. >> >> But anyway, again, 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. >> >> 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 -10 [% 3] gives "-1". >> >> cheers >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >> >> >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
