---------- Forwarded message ---------
From: Simon Iten <itensimon@gmail.com>
Date: Tue, Feb 18, 2020, 10:26
Subject: Re: [PD] rpole bug?
To: Orm Finnendahl <orm.finnendahl@selma.hfmdk-frankfurt.de>

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 <orm.finnendahl@selma.hfmdk-frankfurt.de> 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 <info@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@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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list