What the NaN?
-
Did you know that both
1 < double.NaNand1 > double.NaNare false?! ;PA new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I know, which makes its behavior in Min and Max even more random :D Although, as it turns out, it's not random at all. Min and Max just treat NaN as lower than anything else.
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
NaN means Not a Number, so you cannot compare it to a proper number and get a valid response.
And with that the case is more than closed. :thumbsup:
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
var result = new[] { 1, double.PositiveInfinity, double.NegativeInfinity, double.NaN }.Max(); // Infinity
var result = new[] { 1, double.PositiveInfinity, double.NegativeInfinity, double.NaN }.Min(); // NaN
var isNaNSmaller = double.NaN < 1; // falseSo NaN is not the biggest value, it's still bigger than one, but it's also the smallest value. I hate to sound infinitely negative, but that's messed up :wtf:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
You need to check for NaN before passing to min/max and eventually root out them by code. What happened to the simple rule of checking for unexpected/invalid values before using them? Does everybody now cross the streets without looking, eventually launching an exception if hit by a car?
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
Richard MacCutchan wrote:
So you cannot equate it to any numeric value
Yes you can, and that's the point. I expected either an exception (compile or run time) or at least a predictable weird behavior (well, it's predictable once you know all the edge cases I guess). Now whether you should is a different discussion... :) I found this because I had some weird JavaScript bug by the way, casting some object to a number results in NaN and I was wondering how C# handled the case the followed. NaN is not smaller than 1 (when comparing and when using the Min function), but when both are thrown into the Max function NaN is smaller than 1. Got it :~ Luckily, I've never had to work with NaN in C# because why would there even be a NaN anyway...
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
0/0 should throw a DivideByZeroException (which it does for integers). And apparently 1/0 equals infinity. Now what is it? NaN, infinity or just plain not possible? Doesn't it sound weird (and, indeed, very wrong) that a NUMERIC type has a value "NOT A NUMBER"!? Anyway, when I said "why would there even be a NaN anyway" I was referring to NaN in actual real life business cases that make sense and have practical use :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Sander Rossel wrote:
And apparently 1/0 equals infinity.
No, it does not, and never has.
double x = 1;
double y = 0;
double z = x / y; // InfinityYes it does :~ I'm not making this stuff up, you know (IEEE does that).
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
double x = 1;
double y = 0;
double z = x / y; // InfinityYes it does :~ I'm not making this stuff up, you know (IEEE does that).
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Jochen Arndt wrote:
The implementation of Min and Max is probably not. But a Min function is usually implemented as x < y ? x : y instead of !(x >= y) ? x : y
Actually Min and Max don't treat NaN as they should to get predictable results, as pointed out by Mladen :D
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
I don't saw Mladen's reply when I wrote mine (late in the night) but it explains what happens here. But that implementation produces predictible results: If an element is NaN, it is the smallest number and returned. How should it be treated else? The only other option from my point of view would be throwing an execption (e.g. by using signaling NaNs instead of quite NaNs).
-
No it doesn't, 1/0 is undefined (i.e NaN) and always has been. Various computer systems may try to represent it by some very large or very small value, but that does not alter the fact that it has no mathematical value.
Really man, I completely agree with you there, but .NET (and I guess IEEE) represents 1 / 0 as Infinity and 0 / 0 as NaN. And Infinity behaves different than NaN, so they're not the same (according to .NET/IEEE) no matter what we think of it :sigh:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Really man, I completely agree with you there, but .NET (and I guess IEEE) represents 1 / 0 as Infinity and 0 / 0 as NaN. And Infinity behaves different than NaN, so they're not the same (according to .NET/IEEE) no matter what we think of it :sigh:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
You need to check for NaN before passing to min/max and eventually root out them by code. What happened to the simple rule of checking for unexpected/invalid values before using them? Does everybody now cross the streets without looking, eventually launching an exception if hit by a car?
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
den2k88 wrote:
What happened to the simple rule of checking for unexpected/invalid values before using them?
Now you're talking a religion of which I am a true believer ! So many questions on C# QA could be answered by the posters, themselves, if they had learned to check input values before calling them, and how to use a debugger. I am also in favor of disabling, or hiding, UI controls that are irrelevant to the current context, or which would create errors if clicked, or, which should only be used after specific action(s) by the user.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
-
I know, so always treat it as smallest value, or always as biggest value or, better yet, throw an exception when comparing it to numbers. These results are contradictory and just don't make any sense at all! :~ If this was JavaScript I'd be okay with it, but we're talking C# here. I expected better from C# :sigh:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Sander Rossel wrote:
so always treat it as smallest value, or always as biggest value or, better yet, throw an exception when comparing it to numbers.
If you know you have a scenario where NaN is in play, then test for the NaN and handle accordingly? You should not let a NaN produce an exception on purpose? Maybe I am not getting the big deal here, because I don't see this as a big deal. :sigh:
-
den2k88 wrote:
What happened to the simple rule of checking for unexpected/invalid values before using them?
Now you're talking a religion of which I am a true believer ! So many questions on C# QA could be answered by the posters, themselves, if they had learned to check input values before calling them, and how to use a debugger. I am also in favor of disabling, or hiding, UI controls that are irrelevant to the current context, or which would create errors if clicked, or, which should only be used after specific action(s) by the user.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
BillWoodruff wrote:
I am also in favor of disabling, or hiding, UI controls that are irrelevant to the current context, or which would create errors if clicked, or, which should only be used after specific action(s) by the user.
Absolutely. Even when I start not doing so I end up fixing it because during the tests I elephant up myself. The real problem is that noone programs anymore: now there are frameworks! Never release resources anymore, there is The Framework. Never think about what you have to do, The Framework has already a solution for you! If the solution is not right for your problem, modify the problem! Don't write your components: The Framework is better and there's no discussion on it! The Framework weights several hundred megabytes, has its own version of DLL hell which is not called Dll hell, can cease backwards compatibility every moment and lose its support or be replaced by The Next Framework, which is better! And incompatible. And so on so forth...
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
Sander Rossel wrote:
.NET (and I guess IEEE) represents 1 / 0 as Infinity
No, it does not, where on earth did you get this idea from? How exactly do you represent infinity as a number in a computer?
I got it from simply running the following code in C#... :~
double a = 1;
double b = 0;
double c = a / b; // c is now double.InfinityI'm seeing the result is Infinity right here on my screen and you telling me it isn't and never was :confused:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
You need to check for NaN before passing to min/max and eventually root out them by code. What happened to the simple rule of checking for unexpected/invalid values before using them? Does everybody now cross the streets without looking, eventually launching an exception if hit by a car?
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
I'm writing the function that will be called by users that didn't check their input. At least I should know how to handle their crap :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I got it from simply running the following code in C#... :~
double a = 1;
double b = 0;
double c = a / b; // c is now double.InfinityI'm seeing the result is Infinity right here on my screen and you telling me it isn't and never was :confused:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
0/0 should throw a DivideByZeroException (which it does for integers). And apparently 1/0 equals infinity. Now what is it? NaN, infinity or just plain not possible? Doesn't it sound weird (and, indeed, very wrong) that a NUMERIC type has a value "NOT A NUMBER"!? Anyway, when I said "why would there even be a NaN anyway" I was referring to NaN in actual real life business cases that make sense and have practical use :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
1/0 is NOT infinity! I know you've already stated you're weak at maths, but try to do some basic research before posting non sense like that! 1/x with x -> 0 that is something completely different though! X| OK, I know I'm arguing with an idiot who actually thinks infinity is a number!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
-
1/0 is NOT infinity! I know you've already stated you're weak at maths, but try to do some basic research before posting non sense like that! 1/x with x -> 0 that is something completely different though! X| OK, I know I'm arguing with an idiot who actually thinks infinity is a number!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
I KNOW 1/0 is nonsense and not infinity, but try telling that to C#[^]! X| Then again 1/0 is also not NaN, it's just bogus and an Exception is the only correct outcome, but say that and people go all IEEE on your ass! X|
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I'm writing the function that will be called by users that didn't check their input. At least I should know how to handle their crap :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Remember that not only the users can insert unacceptable values but that other parts of your code can produce them. Either you're 100% sure that to some point in your code the values are all ammissible or you check them, or you document that the values must be checked beforehand. For example I made some extrafast buffer rotation procedures in Assembler (we needed them) and they crash if the number of columns is not a multiple of 64. Since checking each time the function is called would lower the extra speed it is clearly documented to make sure the buffers are allocated in 64 colums multiples. Otherwise I should check them.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
It is not just a C#, it is IEEE 754 And this is how you represented:
7ff0 0000 0000 000016 = Infinity
fff0 0000 0000 000016 = −Infinity
7fff ffff ffff ffff16 = NaNThose first 12 bits correspond to the sign and exponent, and the values 7ff and fff are reserved constants with special meaning. Why? I don't freaking know, I didn't invent IEEE 754. But anywhere you find double it is like that because it is standard, and it is even implemented in the CPU. It is very easy to show it is not C#, see this JSFiddle[^]. Does it make mathematical sense? No. A number system that has a representation for not-a-number makes no sense. --- Although I can argue that a number system with 1/0 = Infinity is possible, it would be a two-point compactification[^] of the real numbers to include -Infinity and Infinity*. Another system with 1/0 = Infinity is the Rieammn Sphere**, but that number system has only one Infinity and include the complex numbers. *: To be clear, that means that you create a topological space where the infinite number line is embedded by a projection in a finite segment. Then the points at the extremes of the segment can't ever be reached, there is no real number low or high enough to reach those points. Then you label then "-Infinity" on the negative side and "Infinity" on the positive side. Clearly those points aren't real numbers, and they break traditional algebra, but they are numbers. Why would you want them? I don't know. **: But I know for the Riemman Spehre, you can extend the real numbers to add the complex infinity point. This is embedding the complex plane in the surface of a unit sphere, such that the opposite point from 0 is never reached by any complex number. Then you label that point "Complex Infinity". Then you go to say that 1/0 = Complex Infinity, and 1 / Complex Infinity = 0 - now you can divide by infinity and solve integrations the old way. Yet, it also breaks algebra. Of course, this is problematic, and mathematicians left the idea in favor of Limits. The modern well-behaved solution (that doesn’t break algebra) is Hyperreals.
