How do you test if float is Nan? == and is doesn't seem to work.

float num;
if (num ==/is float.nan)
{
// true
}
else
{
// false
}

?

"clayasaurus" <clayasaurus@gmail.com> wrote in message news:e4e1qd$jb6$1@digitaldaemon.com...

> How do you test if float is Nan? == and is doesn't seem to work.

Try std.math.isnan().

clayasaurus schrieb am 2006-05-17:
> How do you test if float is Nan? == and is doesn't seem to work.

1)
#
# if(num !<>= 0.0){
#     // ...
# }

2)
# import std.math;
#
# if(isnan(num)){
#     // ...
# }

Thomas

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> clayasaurus schrieb am 2006-05-17:
>> How do you test if float is Nan? == and is doesn't seem to work.
> 
> 1)
> #
> # if(num !<>= 0.0){
> #     // ...
> # }

Nice, learn something new every day.

> 
> 2)
> # import std.math;
> #
> # if(isnan(num)){
> #     // ...
> # }
> 
> Thomas
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFEaqeQ3w+/yD4P9tIRAk/1AJsHaMIYMVQ1GgjTg8Yn3afE8ilMfgCfb+15
> BLGWcCiaGKR3GjBEeXtmZGg=
> =w7vc
> -----END PGP SIGNATURE-----

Thank you Thomas and Jarret :)

~ Clay

clayasaurus wrote:
> How do you test if float is Nan? == and is doesn't seem to work.
> 
> float num;
> if (num ==/is float.nan)
> {
> // true
> }
> else
> {
> // false
> }
> 
> ?

I think this should work as well:

if (num == num) {
    // not NaN
} else {
    // NaN
}


xs0

xs0 wrote:
> I think this should work as well:
> 
> if (num == num) {
>     // not NaN
> } else {
>     // NaN
> }

Indeed! This works just fine in VC on x86, but fails miserably on x64...

In a release build the VC8 x64 compiler optimized that "if" to "if(1)" :D

Here's the assembly from a debug build:

inline bool _is_nan( double d ) { return !(d==d); }
0000000000404000  movsd       mmword ptr [rsp+8],xmm0
0000000000404006  push        rdi
0000000000404007  sub         rsp,10h
000000000040400B  mov         rdi,rsp
000000000040400E  mov         rcx,4
0000000000404018  mov         eax,0CCCCCCCCh
000000000040401D  rep stos    dword ptr [rdi]
000000000040401F  movsd       xmm0,mmword ptr [d]
0000000000404025  ucomisd     xmm0,mmword ptr [d]
000000000040402B  je          citkTypes::_is_nan+36h (404036h)
000000000040402D  mov         dword ptr [rsp],1
0000000000404034  jmp         citkTypes::_is_nan+3Dh (40403Dh)
0000000000404036  mov         dword ptr [rsp],0
000000000040403D  mov         al,byte ptr [rsp]
0000000000404040  add         rsp,10h
0000000000404044  pop         rdi
0000000000404045  ret

According to
http://www.ews.uiuc.edu/~cjiang/reference/vc314.htm
they should not have been checking for ZF,PF,CF==1,0,0, but the code only checks ZF?

Since by definition a NaN is not equal to anything, including itself, I suppose it's a compiler bug?

L.

I really should proof read my posts first; scrap the 'not':
> they should have been checking for ZF,PF,CF==1,0,0, but the code only checks ZF? 

Lionello Lunesu wrote:
> xs0 wrote:
>> I think this should work as well:
>>
>> if (num == num) {
>>     // not NaN
>> } else {
>>     // NaN
>> }
> 
> Indeed! This works just fine in VC on x86, but fails miserably on x64...
> 
> In a release build the VC8 x64 compiler optimized that "if" to "if(1)" :D
> 
> Here's the assembly from a debug build:
> 
> inline bool _is_nan( double d ) { return !(d==d); }
> 0000000000404000  movsd       mmword ptr [rsp+8],xmm0
> 0000000000404006  push        rdi
> 0000000000404007  sub         rsp,10h
> 000000000040400B  mov         rdi,rsp
> 000000000040400E  mov         rcx,4
> 0000000000404018  mov         eax,0CCCCCCCCh
> 000000000040401D  rep stos    dword ptr [rdi]
> 000000000040401F  movsd       xmm0,mmword ptr [d]
> 0000000000404025  ucomisd     xmm0,mmword ptr [d]
> 000000000040402B  je          citkTypes::_is_nan+36h (404036h)
> 000000000040402D  mov         dword ptr [rsp],1
> 0000000000404034  jmp         citkTypes::_is_nan+3Dh (40403Dh)
> 0000000000404036  mov         dword ptr [rsp],0
> 000000000040403D  mov         al,byte ptr [rsp]
> 0000000000404040  add         rsp,10h
> 0000000000404044  pop         rdi
> 0000000000404045  ret
> 
> According to
> http://www.ews.uiuc.edu/~cjiang/reference/vc314.htm
> they should not have been checking for ZF,PF,CF==1,0,0, but the code only checks ZF?
> 
> Since by definition a NaN is not equal to anything, including itself, I suppose it's a compiler bug?

Definitely. I've seen that sort of behaviour before in VC++.
<cynic> Does anyone at Microsoft understand floating point arithmetic? </cynic>

Don Clugston wrote:
> Lionello Lunesu wrote:
>> Since by definition a NaN is not equal to anything, including itself, I suppose it's a compiler bug?
> 
> Definitely. I've seen that sort of behaviour before in VC++.
> <cynic> Does anyone at Microsoft understand floating point arithmetic? </cynic>

I must mention that I have the unstable floating point optimizations turned on, /fp:fast.. I'll have to try the default before trashing the VC team ;)

L.

Don Clugston wrote:
>> Since by definition a NaN is not equal to anything, including itself, I suppose it's a compiler bug?
> 
> Definitely. I've seen that sort of behaviour before in VC++.
> <cynic> Does anyone at Microsoft understand floating point arithmetic? </cynic>

At least up until VC6, it did not check the parity bit for floating point comparisons (the P bit is set if one of the operands is NaN). In fact, I know of no C++ compiler other than DMC++ that does this correctly.

VC dropping support for 80 bit long doubles is not an encouraging sign.

This is typical for C++ compiler vendors. Handling of NaN arguments to the math.h functions is routinely erratic and buggy. This can be traced back to the Standards committee, who failed to specify NaN behavior.