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

Kjetil Matheussen k.s.matheussen at gmail.com
Tue Sep 10 11:12:33 CEST 2013


Perhaps expr should check for denormals as well?

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.




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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20130910/c02fa34f/attachment.htm>


More information about the Pd-dev mailing list