[PD] Fwd: rpole bug?

[Simon Iten]

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 <itensimon at gmail.com>
Date: Tue, Feb 18, 2020, 10:26
Subject: Re: [PD] rpole bug?
To: Orm Finnendahl <orm.finnendahl at 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 at 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 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
> _______________________________________________
> 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/20200218/e27f4873/attachment-0001.html>