not-a-number's

[Mischa Baars]

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