I think this was ment for the list:
On May 15, 2006, at 5:21 PM, Sciss wrote:
all programming languages i know of, have modulo work with floating
point numbers and hence spit out floating point numbers. i'd find
it very usefull to be able to calculate for example 7.5 mod pi =
1.2168146928204 etc. ; at the moment it would return 1 which is not
so useful. i though all numbers in PD are floats anyways ... ?however changing the existing object is not a good idea, it will
certainly be not backward compatible.best, -sciss-
Am 15.05.2006 um 12:51 schrieb Hans-Christoph Steiner:
On Fri, 12 May 2006, geiger wrote:
On Thu, 11 May 2006, Frank Barknecht wrote:
[div] ... and [mod] in that case.
Some definitions of [mod] extend it to be able to use the real
numbers as first parameter. So 2.45 mod 2 would be 0.45. I think this could be a good extension to Pd's mod object, and it should also be backwards compatible to its current behaviour. The change inside the code would be trivial. Question is how many
patches depend on the truncation after the mod operation.I think that [mod] should probably do whatever ANSI C or ISO math
stuff does, which I think it currently is doing. Most programming
languages follow these conventions, so its a good idea for Pd to
as well.But the object you propose does sound handy, so maybe it should be
a separate object, like [floatmod]..hc
If you are not part of the solution, you are part of the problem.
-
Eldridge Cleaver
couldn't [%] be changed to work as in max then? let the init argument decide whether to fmod or not. so [% 0.125] would be floating modulo and [% 2] plain integer. that should not break anything. _f
On 15.05.2006, at 23:25, Hans-Christoph Steiner wrote:
I think this was ment for the list:
On May 15, 2006, at 5:21 PM, Sciss wrote:
all programming languages i know of, have modulo work with floating point numbers and hence spit out floating point numbers. i'd find it very usefull to be able to calculate for example 7.5 mod pi = 1.2168146928204 etc. ; at the moment it would return 1 which is not so useful. i though all numbers in PD are floats anyways ... ?
however changing the existing object is not a good idea, it will certainly be not backward compatible.
best, -sciss-
Am 15.05.2006 um 12:51 schrieb Hans-Christoph Steiner:
On Fri, 12 May 2006, geiger wrote:
On Thu, 11 May 2006, Frank Barknecht wrote:
[div] ... and [mod] in that case.
Some definitions of [mod] extend it to be able to use the real numbers as first parameter. So 2.45 mod 2 would be 0.45. I think this could be a good extension to Pd's mod object, and it should also be backwards compatible to its current behaviour. The change inside the code would be trivial. Question is how many patches depend on the truncation after the mod operation.
I think that [mod] should probably do whatever ANSI C or ISO math stuff does, which I think it currently is doing. Most programming languages follow these conventions, so its a good idea for Pd to as well.
But the object you propose does sound handy, so maybe it should be a separate object, like [floatmod].
.hc
#| fredrikolofsson.com klippav.org musicalfieldsforever.com |#
that would be really confusing IMO, because generally pd doesn't
distinguish between ints and floats, so in max you'll have to
explicitly write [+ 0.] or [+ 0] which is not applicable to pd. by
introducing this technique to pd, people would possibly think that pd
_does_ make a difference.
Am 16.05.2006 um 01:08 schrieb Fredrik Olofsson:
couldn't [%] be changed to work as in max then? let the init
argument decide whether to fmod or not. so [% 0.125] would be
floating modulo and [% 2] plain integer. that should not break
anything. _f
On Mon, 15 May 2006, Hans-Christoph Steiner wrote:
On May 15, 2006, at 5:21 PM, Sciss wrote:
however changing the existing object is not a good idea, it will certainly be not backward compatible.
Yes, might be true. Thats why I asked how many people are using mod in order to do the operation and truncate the result. Personally I never used it that way.
man fmod:
DESCRIPTION The fmod() function computes the remainder of dividing x by y. The return value is x - n * y, where n is the quotient of x / y, rounded towards zero to an integer.
Günter
best, -sciss-
Am 15.05.2006 um 12:51 schrieb Hans-Christoph Steiner:
On Fri, 12 May 2006, geiger wrote:
On Thu, 11 May 2006, Frank Barknecht wrote:
[div] ... and [mod] in that case.
Some definitions of [mod] extend it to be able to use the real numbers as first parameter. So 2.45 mod 2 would be 0.45. I think this could be a good extension to Pd's mod object, and it should also be backwards compatible to its current behaviour. The change inside the code would be trivial. Question is how many patches depend on the truncation after the mod operation.
I think that [mod] should probably do whatever ANSI C or ISO math stuff does, which I think it currently is doing. Most programming languages follow these conventions, so its a good idea for Pd to as well.
But the object you propose does sound handy, so maybe it should be a separate object, like [floatmod].
.hc
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Fredrik Olofsson -
geiger -
Hans-Christoph Steiner -
Sciss