<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>Hi,<br><br> 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.<br><br>--<br>Orm <br><br><div class="gmail_quote">Am 15. Februar 2020 18:24:48 MEZ schrieb Christof Ressi <info@christofressi.com>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<p>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 <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/IEEE_754">https://en.wikipedia.org/wiki/IEEE_754</a>).</p>
<p>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. <br>
</p>
<p>BTW, this is also the reason why you get artifacts when indexing
an audio buffer with a large float index. <br>
</p>
<p>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.</p>
<p>Christof<br>
</p>
<div class="moz-cite-prefix">On 15.02.2020 17:36, Simon Iten wrote:<br>
</div>
<blockquote type="cite" cite="mid:24058CF6-AC09-4514-832A-7AD6D63FB0B7@gmail.com">
<pre class="moz-quote-pre" wrap="">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?
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
</blockquote></div><hr>Orm Finnendahl<br>Komposition<br>HfMDK<br>Eschersheimer Landstraße 29-39<br>60322 Frankfurt</body></html>