[PD] counter question

Andy Farnell padawan12 at obiwannabe.co.uk
Fri Jul 27 08:48:43 CEST 2007

On Thu, 26 Jul 2007 19:45:32 +0200
Derek Holzer <derek at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Use the source

More information about the Pd-list mailing list