<div dir="auto">sorry went off list.<div dir="auto"><br></div><div dir="auto">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...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Simon Iten</strong> <span dir="auto"><<a href="mailto:itensimon@gmail.com" target="_blank" rel="noreferrer">itensimon@gmail.com</a>></span><br>Date: Tue, Feb 18, 2020, 10:26<br>Subject: Re: [PD] rpole bug?<br>To: Orm Finnendahl <<a href="mailto:orm.finnendahl@selma.hfmdk-frankfurt.de" target="_blank" rel="noreferrer">orm.finnendahl@selma.hfmdk-frankfurt.de</a>><br></div><br><br><div dir="auto">thanks to both of you!<div dir="auto"><br></div><div dir="auto">a related question:</div><div dir="auto"><br></div><div dir="auto">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...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 15, 2020, 18:38 Orm Finnendahl <<a href="mailto:orm.finnendahl@selma.hfmdk-frankfurt.de" rel="noreferrer noreferrer" target="_blank">orm.finnendahl@selma.hfmdk-frankfurt.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    
  
  <div>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 <<a href="mailto:info@christofressi.com" rel="noreferrer noreferrer noreferrer" target="_blank">info@christofressi.com</a>>:<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 href="https://en.wikipedia.org/wiki/IEEE_754" rel="noreferrer noreferrer noreferrer" target="_blank">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>On 15.02.2020 17:36, Simon Iten wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>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></fieldset>
      <pre>_______________________________________________
<a href="mailto:Pd-list@lists.iem.at" rel="noreferrer noreferrer noreferrer" target="_blank">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer noreferrer noreferrer" target="_blank">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</div>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" rel="noreferrer noreferrer noreferrer" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div>
</div>