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 argument).
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....