sorry went off list. to clarify, i am fine with wrapping of the output, so if i hit the higher limit of 32bit it should just start from zero again. it's crucial that it never stops counting though...
---------- Forwarded message --------- From: Simon Iten <[email protected]> Date: Tue, Feb 18, 2020, 10:26 Subject: Re: [PD] rpole bug? To: Orm Finnendahl <[email protected]> thanks to both of you! a related question: what would then be the preferred way to count up (only integers needed) to very high numbers in PD without precision loss? am i better of with line~ or even metro? the speed of counting should be adjustable from very low values to about 8000 hz. i tried a phasor~ solution but ran into the precision loss problem on very slow input rates to phasor... On Sat, Feb 15, 2020, 18:38 Orm Finnendahl < [email protected]> wrote: > Hi, > > to circumvent this limitation you can use a second structure (e.g. using a > second rpole~) to count the overflows, resetting the first rpole when it > reaches a threshold. > > -- > Orm > > Am 15. Februar 2020 18:24:48 MEZ schrieb Christof Ressi < > [email protected]>: >> >> This expected behavior due to limited precision of floating point >> numbers. When a float gets larger and larger, it gradually loses precision >> in the lower bits, because the mantissa has a fixed size (see >> https://en.wikipedia.org/wiki/IEEE_754). >> >> There will be a point where the precision loss exceeds the size of your >> input, so the filter will just stop accumulating. In your case, the input >> is "1". Floating point numbers have a mantissa of 2^23 (without the sign >> bit), so the largest whole number you can represent without truncating >> lower bits is 2^23 = 8,388,608. This is the limit you've experienced in >> your patch. >> >> BTW, this is also the reason why you get artifacts when indexing an audio >> buffer with a large float index. >> >> Interestingly, I couldn't immediatly reproduce this behavior on my system >> (Pd 0.50.2 Windows 32-bit), the limit would be about 8 times as large as >> yours. I think the reason is that the code keeps the filter state in an >> intermediate higher precision register, so the accumulation is not >> immediately lost. When I run your patch with [block~ 1], each accumulation >> step has to be written to an actual 32-bit float, and I can indeed >> reproduce your observation. >> >> Christof >> On 15.02.2020 17:36, Simon Iten wrote: >> >> i have a strange behaviour with rpole, see attached patch. >> >> basically it stops accumulating at a certain point (depending on the input >> value) >> ist this a “rounding” problem? >> >> >> >> _______________________________________________pd-l...@lists.iem.at mailing >> list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >> ------------------------------ > Orm Finnendahl > Komposition > HfMDK > Eschersheimer Landstraße 29-39 > 60322 Frankfurt > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
