not-a-number's

[Mischa Baars]

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
>