[PD] [mod] vs [%]

[Alexandre Torres Porres]

HAH, % in SuperCollider will work as [mod] in Pd

-7 % 5 gives us -3


2016-05-08 1:09 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> 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/7b0a15a8/attachment-0001.html>