[PD] rpole bug?

[Orm Finnendahl]

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 <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
>
>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-list at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200215/d95185a3/attachment-0001.html>