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 <[email protected]>: > > http://article.gmane.org/gmane.comp.multimedia.puredata.general/56291/match=div+mod > > > On Saturday, May 7, 2016 11:45 PM, Alexandre Torres Porres < > [email protected]> wrote: > > > On Sat, May 7, 2016 at 6:44 PM, Miller Puckette <[email protected]> wrote: > > I _think_ (but am not sure) that "%" works differently on different > CPU architectures. > > > 2016-05-07 20:20 GMT-03:00 Matt Barber <[email protected]>: > > % 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 > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
