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
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
