[PD] division with remainder
f at fredrikolofsson.com
Tue May 16 01:08:38 CEST 2006
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.
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
>>>> 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
>>>> 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
>>> But the object you propose does sound handy, so maybe it should be a
>>> separate object, like [floatmod].
fredrikolofsson.com klippav.org musicalfieldsforever.com
More information about the Pd-list