[PD] [mod] vs [%]

[Alexandre Torres Porres]

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 <jancsika at 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 <
> porres at gmail.com> wrote:
>
>
> On Sat, May 7, 2016 at 6:44 PM, Miller Puckette <msp at 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 <brbrofsvl at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160508/8e846b42/attachment.html>