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