On Tue, Sep 10, 2013 at 11:12 AM, Kjetil Matheussen <k.s.matheus...@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: > 1. Check for denormals in expr > 2. 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 <katjavet...@gmail.com> wrote: >> >> On Tue, Sep 10, 2013 at 10:21 AM, Kjetil Matheussen >> <k.s.matheus...@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 > > _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
