[PD] rpole bug?

[Christof Ressi]

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