On 01/17/2013 01:08 PM, Gabriel Paubert wrote:
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.
Actually it is the correct way, as long as you stick to the conventions.
A QNaN is not supposed to change into anything, also not with the pow().
Only the other way around. Normal numbers can change into QNaN's.
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
