[PD] Infinite and NaN float values?
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