[PD] counter question
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