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 |#