[PD] division with remainder

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