On Tue, Sep 10, 2013 at 11:12 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
Perhaps expr should check for denormals as well?
Math objects should be able to output denormals. Without that we could not even make test patches to find or debug denormals-issues in other classes.
Two fixes then:
- Check for denormals in expr
- Add an isnormal call to the floating value in vd~ to avoid crashing if
getting a value that fails the if (delsamps < 1.00001f) delsamps = 1.00001f; if (delsamps > limit) delsamps = limit; checks in there.
NAN is unordered, the greater-than test does not handle it indeed.The PD_BIGORSMALL() macro / function as defined in m_pd.h may work well here. Some processors don't have a fast implementation of isnan() etc.
On Tue, Sep 10, 2013 at 10:57 AM, katja katjavetter@gmail.com wrote:
On Tue, Sep 10, 2013 at 10:21 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote: ...
In Pd, should objects be able to handle (i.e. "not crash") when they get input values of nan and inf, or should they instead make sure that nan and inf never can be sent out of the objects, or both?
It is not so much of a problem if an object puts out denormals incidentally and most classes do not provide a check, for reasons of performance. Most important is that objects can not get into a state of recycling nan / inf for a longer period of time (like in a recursive filter's state variable). For table writers it is customary to make sure they don't write any denormal, because other objects have access to the data and could make denormals to recycle. So it is the writing object that has or should have anti-denormals-protection. When using an [s~] and [r~] pair for signal connection, denormals don't go through because [s~] does the check too.
Katja