[PD] counter question

Mathieu Bouchard matju at artengine.ca
Thu Jul 26 22:57:52 CEST 2007

On Thu, 26 Jul 2007, Derek Holzer wrote:

> If I use a simple counter structure that continues to generate a number
> from [f] & [+1] at every bang, and use [mod] to keep that number within
> certain bounds, then eventually it will require more and more memory to
> hold the number coming from [f], right? Is this a potential memory leak,
> or is there a cap to how much memory it will hold?

Float takes 4 bytes; the atom containing the float takes 8 or 16 bytes. 
The object containing the atom is bigger. Those things always take the 
same amount of memory. The limit of 4 bytes for the float itself means 
that numbers are limited. Of those 4 bytes, 1 byte stores the degree of 
precision of the float, so 3 bytes left for the actual value. From this 
you can find out that the last contiguous whole number is 16777216.

> I've seen that [f] resets itself somewhere around 8.394e+06.

The counter should stand still at 16777216. The value you mention is most 
likely exactly half that value. If it resets then that is definitely a 
bug, but I have never seen that. Such a counter should just stand still 
when it reaches that max, as 16777216+1=16777216 (the next integer doesn't 
exist in the float format, and it won't skip to 16777218 either, because 
of the kind of rounding that happens)

> Or in less-theoretical and more practical terms, would it make sense to 
> reset [f] to 0 every so often, or let it run forever towards infinity?

Insert [mod] in your [f] [+] loop. That will reset your counter.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

More information about the Pd-list mailing list