On 2013-01-17 06:53:45 +0100, Mischa Baars wrote: > Also this was not what I intended to do, I was trying to work with quiet > not-a-numbers explicitly to avoid the 'invalid operation' exception to be > triggered, so that my program can work it's way through the calculations > without being terminated by the intervention of a signal handler. When any > not-a-number shows up in results after execution, then you know something > went wrong. When the program does what it is supposed to do, you could > remove any remaining debug code, such as the boundary check in the > trigonometric functions.
Checking whether a (final) result is NaN is not always the correct way to detect whether something was wrong, because a NaN can disappear. For instance, pow(NaN,0) gives 0, not NaN. You need to check the "invalid operation" exception flag (if you don't want a trap). And this flag will also be set by the <=, <, >, >= comparisons when one of the operands is NaN, which should be fine for you. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
