Apr
18th | 2008
Comparison of a double with double.Nan (Not a Number) will always return false. Even (double.Nan == double.Nan) return false and indeed, from IEEE 754 specs: equality comparison between two Nan is always false. If we want to check whether a specific double is Nan, double.IsNan() shall be used. Lets look at how the IsNan method is implemented (using Reflector):
public static bool IsNaN(double d) { return (d != d); }
My question is why double.Nan exist? It only creates confusion…
By JV on Apr 18, 2008 | Reply
You already gave the answer yourself. Because they implemented IEEE 754…
By Gabriel Rodriguez on Apr 18, 2008 | Reply
any smart reason of why the equality comparison always returns false?
By Shahar Y on Apr 18, 2008 | Reply
JV,
I am sure they didn’t implement all of the IEEE specs, so they could just ignore this one too.
Anyway, I was just saying that this is a strange behavior. Most of the developers don’t know IEEE specs…
By Shahar Y on Apr 18, 2008 | Reply
Hi Gabriel Rodriguez,
Nan could be generated by many different mathematical operations and: (Square(-1) == Log(0)) shall indeed return false. But the problem is that (Square(-1) == Square(-1)) will also return false…
By Mark S. Rasmussen on Apr 18, 2008 | Reply
It’s logic (literally). The same goes for NULL comparisons in any database. You cannot compare two unknowns, and that’s exactly what NaN is, it’s an unknown. All we know is that it’s definitely not a number. Other than that it could be anything.
If I present you with two wrapped boxes and ask you to tell me if the contents are equal, what would you answer?
By aalmada on Apr 18, 2008 | Reply
double.NaN and double.Infinity exist for mathematical reasons. The following operations, instead of throwing exceptions, return these values:
var x = 1.0 / 0.0; // double.Infinity
var y = Math.Sin(0.0); // double.NaN
By SY on Apr 18, 2008 | Reply
Sometimes its better to throw exception if your data gets corrupted or unknown. I do think it is much better then using NANs.
By Casper Bang on Apr 18, 2008 | Reply
On a related note, I find it a much bigger problem in practice, that Double.MIN_VALUE yields 4.9E-324, the smallest *positive* number and not -1.7976931348623157E308, the actual smallest number. Java/JavaScript are the only languages I know where this is the case.
By ChrisW on Apr 18, 2008 | Reply
Years ago I found a bug in SQL Server. As I recall, if you save a double NAN into a table, and the column that contains that NAN is indexed, then attempts to SELECT that value out via that index will crash SQL Server. This happens even if you’re not using that value in the index anyway (e.g., the index is MyInt + MyDouble, and you select WHERE MyInt=7, and the row with 7 has a NAN, then SQL Server will crash)
I reported this in SQL 7, it remained in SQL 2000. Dunno if it’s been fixed yet.
By carsten on Apr 18, 2008 | Reply
Apart from the mathematical reason which has already been pointed out, it is very handy to use for variablres where the value is currently undefined; e.g. very handy to get started when computing min or max from a collection. You just have to use it right, ie use isNaN instead of ==.
Matter of fact, you can use ==. x==x is the same as !Double.isNaN(x) since all numnbers which are not NaN are euqal to them selves. But this is clearly just a smart-ass hack. Use Double.isNaN() in real live.
By km on Jun 8, 2008 | Reply
aalmada, why should Math.Sin(0.0) return a NaN ? Isn’t a sine of 0 just a 0 ?
By aalmada on Jun 9, 2008 | Reply
@km
Yes, you’re right… :-/