[PD] Infinite and NaN float values?

Claude Heiland-Allen claudiusmaximus at goto10.org
Mon Aug 16 20:44:52 CEST 2010

On 16/08/10 18:59, Matteo Sisti Sette wrote:
> Is this expected behaviour?

Yes.  IEEE floating point (used by most common CPUs, though GPUs might 
not support all features) is a bit warty.

> If so i guess infinities and NaN have been
> recently introduced, haven't they?

No.  But Pd tries to guard against them.

> However there seem to be some inconsistency: 5/4 returns 0 (as I was
> used to), not +inf. Also, I'm not sure +inf is the value you expect when
> adding something to the greatest representable value... or is it?

Pd [/] guards against division by 0 by outputting 0 instead of 
+infinity, -infinity or NotANumber (depending on the sign of the left 

The reason why NaN and (to a lesser extent?) infinities are discouraged 
by non-scientific software is that it pollutes everything: any 
arithmetic operation you try to do with NaN gives you a NaN (or worse, 
an unexpected result: comparisons always give False so the three-way 
partition >x ==x <x doesn't hold).  For scientific software NaN can be 
useful, to indicate that the algorithms aren't good enough or that the 
input was bad.

> Also I cannot seem to find a way to write inf's or NaN as a literal (in
> a message box), and I cannot find an [isNaN] or similar object... that's
> why I wonder if this is a feature or a bug.

[expr isnan($f1)], perhaps?  It creates, but I didn't manage to create a 
NaN to test yet (expr guards against division by zero too).

> Also, sliders seem not to like them.
> If you feed a NaN (or maybe +Inf, I'm not sure) to a slider, it makes

NaN compares 'False' for everything, my guess is that it checks for out 
of bounds (x > top || bottom > x) which gives false for NaN, so it 
assumes it's in the right range and passes a NaN to the graphics engine, 
which then goes beserk - more robust would be !(x < top && bottom < x) 
which should work even for NaN....


More information about the Pd-list mailing list