<div dir="ltr">Perhaps expr should check for denormals as well?<div><br></div><div>Two fixes then:</div><div>1. Check for denormals in expr</div><div>2. Add an isnormal call to the floating value in vd~ to avoid crashing if getting a value</div>
<div> that fails the</div><div><div> if (delsamps < 1.00001f) delsamps = 1.00001f;</div><div> if (delsamps > limit) delsamps = limit;</div><div> checks in there.</div></div><div><br></div><div><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 10:57 AM, katja <span dir="ltr"><<a href="mailto:katjavetter@gmail.com" target="_blank">katjavetter@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Sep 10, 2013 at 10:21 AM, Kjetil Matheussen<br>
<<a href="mailto:k.s.matheussen@gmail.com">k.s.matheussen@gmail.com</a>> wrote:<br>
...<br>
<div class="im">> In Pd, should objects be able to handle (i.e. "not crash") when they get<br>
> input values of nan and inf, or should they instead make sure that<br>
> nan and inf never can be sent out of the objects, or both?<br>
<br>
</div>It is not so much of a problem if an object puts out denormals<br>
incidentally and most classes do not provide a check, for reasons of<br>
performance. Most important is that objects can not get into a state<br>
of recycling nan / inf for a longer period of time (like in a<br>
recursive filter's state variable). For table writers it is customary<br>
to make sure they don't write any denormal, because other objects have<br>
access to the data and could make denormals to recycle. So it is the<br>
writing object that has or should have anti-denormals-protection. When<br>
using an [s~] and [r~] pair for signal connection, denormals don't go<br>
through because [s~] does the check too.<br>
<span class="HOEnZb"><font color="#888888"><br>
Katja<br>
</font></span></blockquote></div><br></div>