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

On Thu, 26 Jul 2007 19:45:32 +0200 Derek Holzer derek@umatic.nl 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?

No, it will always use sizeof(float) ehatever is stuck in it. Probably 4 bytes.

Is this a potential memory leak, or is there a cap to how much memory it will hold?

No, it stays the same, whatever is used to store the float.

Likewise, is there a max limit to the number that can be stored in [f]? I've seen that [f] resets itself somewhere around 8.394e+06. Does that mean that [f] resets itself and clears the memory?

It never changes how much memory is used. But the behaviour when a value overflows depends. Not sure how Pd handles it, but at the lowest level it depends on the processor and the compiler and what happens if the overflow flag is set and what the code does with it if it's trapped. Because of all this it's best to treat overflows and underflows as UNDEFINED.

Sometimes it wraps, so if the maximum value is n then it goes {...n-2, n-1, n, -n-1, -n, -n+1...}

I think in Pd (at least on x86 32 bit) it actually just stops the end of the universe where time stands still :), ie overflow doesn't thow an exception and it just stays with the max value there.

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?

I was gonna say in *practical terms* probably doesn't matter unless you have a permenant installation that runs a life support or nuclear plant, but then I'm thinking 9e+06 is quite small really, maybe you should worry, maybe you should panic!! :)

best, d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 37: "Convert a melodic element into a rhythmic element"

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

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?

Likewise, is there a max limit to the number that can be stored in [f]? I've seen that [f] resets itself somewhere around 8.394e+06. Does that mean that [f] resets itself and clears the memory?

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?

best, d.

Hi all,

I often make counters using [moses], see attachement.

Tim

#N canvas 150 46 268 264 10; #X obj 94 96 f; #X msg 195 133 0; #X obj 144 96 moses 5; #X obj 94 47 metro 200; #X obj 94 22 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1 1 ; #X obj 144 132 + 1; #X floatatom 94 176 5 0 0 0 - - -; #X obj 72 47 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X floatatom 204 51 5 0 0 0 - - -; #X connect 0 0 2 0; #X connect 0 0 6 0; #X connect 1 0 0 1; #X connect 2 0 5 0; #X connect 2 1 1 0; #X connect 3 0 0 0; #X connect 4 0 3 0; #X connect 5 0 0 1; #X connect 7 0 0 0; #X connect 8 0 2 1;