Re: [PD] [mod] vs [%]

[Matt Barber]

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 
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 :
>
>>
>> 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  wrote:
>>
>> I _think_ (but am not sure) that "%" works differently on different
>> CPU architectures.
>>
>>
>> 2016-05-07 20:20 GMT-03:00 Matt Barber :
>>
>> ​% 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

Re: [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 :

> 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 :
>
>>
>> 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  wrote:
>>
>> I _think_ (but am not sure) that "%" works differently on different
>> CPU architectures.
>>
>>
>> 2016-05-07 20:20 GMT-03:00 Matt Barber :
>>
>> ​% 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

Re: [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 :

>
> 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  wrote:
>
> I _think_ (but am not sure) that "%" works differently on different
> CPU architectures.
>
>
> 2016-05-07 20:20 GMT-03:00 Matt Barber :
>
> ​% 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

Re: [PD] [mod] vs [%]

[Jonathan Wilkes via Pd-list]

http://article.gmane.org/gmane.comp.multimedia.puredata.general/56291/match=div+mod
 

On Saturday, May 7, 2016 11:45 PM, Alexandre Torres Porres 
 wrote:
 

 
On Sat, May 7, 2016 at 6:44 PM, Miller Puckette  wrote:

I _think_ (but am not sure) that "%" works differently on different
CPU architectures.

 2016-05-07 20:20 GMT-03:00 Matt Barber :

​% 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

[PD] [mod] vs [%]

[Alexandre Torres Porres]

>
> On Sat, May 7, 2016 at 6:44 PM, Miller Puckette  wrote:
>
>> I _think_ (but am not sure) that "%" works differently on different
>> CPU architectures.
>>
>
2016-05-07 20:20 GMT-03:00 Matt Barber :

> ​% 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