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.