On Tue, Sep 10, 2013 at 1:47 PM, katja katjavetter@gmail.com wrote:
On Tue, Sep 10, 2013 at 12:09 PM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
On Tue, Sep 10, 2013 at 11:58 AM, katja katjavetter@gmail.com wrote:
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.
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.