quote:Original post by iamjoesname
If you run fallenang3l''s code in .NET 2003, b = 1.#INF, or positive infinity, non NaN. This makes me wonder about three things. One, why was it changed from VC++6 to VC++7, since (at least to me) it makes more sense to have NaN returned for an undefined result rather than positive infinity? Two, why is a hardware exception not thrown, as is the case with integer division by 0? Third, if you search through MSDN, there''s a section on C++ Multiplicative Operators which says "Division by 0 in either a division or a modulus expression is undefined and causes a run-time error." Not only is the result here not undefined (it''s actually positive infinity), but it does not cause a run-time error. Apparently, Microsoft sometimes doesn''t even conform to it''s own documentation--kind of like b != b, eh?
[edited by - iamjoesname on January 18, 2004 1:45:04 AM]
1) NaN is the result of floating point operations that are mathematically undefined. 1.0/0.0 is infinite (represented as a number with maximum exponent - 127 for float, 1023 for double - and zero mantissa), ok, but 0.0/0.0 is Not a Number (NaN)
2) It depends on the architecture. There are signalling NaNs and non-signalling NaNs. When a signalling NaN is returned, a hardware exception is raised (if the hardware supports it) and it is converted to a non-signalling NaN.
3) I assume the page referred to integer operations: I believe the modulus operator is not defined for floating-point numbers. As for the reason for floats'' behaviour, that''s the way the IEEE 754 standard wants it. It also states that NaN != X for all values of X,
including NaN.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan