[PD-dev] Whose fault is this crash? (nan and inf)

[katja]

On Tue, Sep 10, 2013 at 11:12 AM, Kjetil Matheussen
<k.s.matheussen at 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 <katjavetter at gmail.com> wrote:
>>
>> On Tue, Sep 10, 2013 at 10:21 AM, Kjetil Matheussen
>> <k.s.matheussen at 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
>
>