Strange behaviour with numeric_limits<double>::quiet_NaN ()
-
Hello, Ok, here's the (very simplified) code that's been causing me headaches :
double f = numeric_limits<double>::quiet_NaN ();
int n = (f == numeric_limits<double>::quiet_NaN ());Can someone *please* explain why n is always 0 here?? After the second line is executed, the debugger shows:
std::numeric_limits<double>::quiet_NaN returned 1.#QNAN00000000000 double
f 1.#QNAN00000000000 doubleIn case this is some kind of processor issue, I'll should also mention that I'm using VC++ 2005 on an AMD Turion 64 running Windows XP. Thx ! Sly
-
Hello, Ok, here's the (very simplified) code that's been causing me headaches :
double f = numeric_limits<double>::quiet_NaN ();
int n = (f == numeric_limits<double>::quiet_NaN ());Can someone *please* explain why n is always 0 here?? After the second line is executed, the debugger shows:
std::numeric_limits<double>::quiet_NaN returned 1.#QNAN00000000000 double
f 1.#QNAN00000000000 doubleIn case this is some kind of processor issue, I'll should also mention that I'm using VC++ 2005 on an AMD Turion 64 running Windows XP. Thx ! Sly
if you have condition of exceptipon say a case of divide by zero of double then you get this value 1.#QNAN00000000000. Where NAN represents Not a Number([^]) Now in this case of divide by zero double numerator = 0; double denominator = 0; double d = static_cast<double>(numerator)/static_cast<double>(denominator); value of d is not infinite, but it cannot be calculated, so it given as NaN. well about the second line
int n = (f == numeric_limits<double>::quiet_NaN ());the value of n is compiler dependent so it will change accordingly. for Vs 2005 it may be 0 for some other earlier versions it may be 1.Величие не Бога может быть недооценена.
modified on Thursday, March 4, 2010 6:31 AM
-
Hello, Ok, here's the (very simplified) code that's been causing me headaches :
double f = numeric_limits<double>::quiet_NaN ();
int n = (f == numeric_limits<double>::quiet_NaN ());Can someone *please* explain why n is always 0 here?? After the second line is executed, the debugger shows:
std::numeric_limits<double>::quiet_NaN returned 1.#QNAN00000000000 double
f 1.#QNAN00000000000 doubleIn case this is some kind of processor issue, I'll should also mention that I'm using VC++ 2005 on an AMD Turion 64 running Windows XP. Thx ! Sly
See [^]:
A comparison with a NaN always returns an unordered result even when comparing with itself. The comparison predicates are either signaling or non-signaling, the signaling versions signal an invalid exception for such comparisons. The equality and inequality predicates are non-signaling so x = x returning false can be used to test if x is a quiet NaN. The other standard comparison predicates all signal if they receive a NaN operand, the standard also provides non-signaling versions of these other predicates. The predicate isNaN(x) determines if a value is a NaN and never signals an exception.
:)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
See [^]:
A comparison with a NaN always returns an unordered result even when comparing with itself. The comparison predicates are either signaling or non-signaling, the signaling versions signal an invalid exception for such comparisons. The equality and inequality predicates are non-signaling so x = x returning false can be used to test if x is a quiet NaN. The other standard comparison predicates all signal if they receive a NaN operand, the standard also provides non-signaling versions of these other predicates. The predicate isNaN(x) determines if a value is a NaN and never signals an exception.
:)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Thanks to the both of you for the explanation! I ending up changing all the relevant code to use isnan(f) instead of direct comparisons and everything works fine now but I was still wondering why a direct comparison with a NaN always returned 0 on my compiler. Now I understand! :-D
