On 01/17/2013 04:33 PM, Mischa Baars wrote:
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.
I'm would be very happy to write you an update to the compiler, but it
seems I can't get gcc-4.7.2 to compile. I was just enjoying the newest
glibc, which finally is. Can I now please try to finish the arctan for
glibc?
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
