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

Kjetil Matheussen k.s.matheussen at gmail.com
Tue Sep 10 14:01:40 CEST 2013


On Tue, Sep 10, 2013 at 1:47 PM, katja <katjavetter at gmail.com> wrote:

> On Tue, Sep 10, 2013 at 12:09 PM, Kjetil Matheussen
> <k.s.matheussen at gmail.com> wrote:
> > On Tue, Sep 10, 2013 at 11:58 AM, katja <katjavetter at gmail.com> wrote:
> >>
> >> 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.
> >>
> >
> > Yes, but the problem is that [expr 1/0.00000000000000000000001] sends out
> > inf.
>
> I meant to say denormals and non-numbers, sorry. For example, this
> gives 'inf' in Pd:
>
> [2(
> |
> [pow 1024]
>
> and this gives '-nan':
>
> [2(
> |
> [pow 1024]
> |
> [* 0]
>
> Since most processors don't flush denormals and non-numbers to zero by
> default, Pd classes have to deal with it in some selective way. If all
> math objects (signal objects in particular) would flush those
> generally undesired numbers to zero, that would make Pd slower. The
> compromise is to flush problematic values wherever they cause a
> serious problem, like recycling NaN's. In your [vd~] example the NaN
> seems to result in an illegal pointer value. The same issue might
> happen in other table reading objects with index inlets ([tabread],
> [tabread4~], [cyclone/poke~]). Did you try that?
>
>
Thank you! That's what I wanted to know.
I'll provide a more thought-through patch for vd~, and perhaps tabread4~
and poke~ as well.

The trouble with vd~ was a real world example (provided by a user) that
made radium (with now has pd embedded) crash. He couldn't continue working
on his song, since pd patches are saved inside radium song files, and radium
crashed as soon as he tried to load the song.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20130910/5bdbf777/attachment.htm>


More information about the Pd-dev mailing list