[PD] rpole bug?
orm.finnendahl at selma.hfmdk-frankfurt.de
Sat Feb 15 18:36:44 CET 2020
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.
Am 15. Februar 2020 18:24:48 MEZ schrieb Christof Ressi <info at christofressi.com>:
>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
>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
>indeed reproduce your observation.
>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
>> ist this a “rounding” problem?
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
Eschersheimer Landstraße 29-39
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list