On Thu, Jan 17, 2013 at 12:21:04PM +0100, Vincent Lefevre wrote:
> 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.
Actually 1, but that's a detail. NaN typically propagate, but there
are a few exceptions.
> 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.
Hmm, are you sure that this part is properly implemented in gcc, using
unordered compare versus ordered compare instructions depending on
the operator you use?
At least on PPC, floating point compares always use the unordered
instruction (fcmpu) and never the ordered one (fcmpo), so exceptions
flags are never set.
Regards,
Gabriel
