|
That's just a C# fudge. Mathematically that is not correct.
|
|
|
|
|
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 = NaN
Those 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.
|
|
|
|
|
This is fun.
So what is the value of the interval between -infinity and infinity? Tee hee...
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
The more I read on this subject, the more I regret not doing advanced maths when I was at school.
|
|
|
|
|
|
Theraot wrote: A number system that has a representation for not-a-number makes no sense. Thank you!
|
|
|
|
|
This is how you represent infinity in a computer:
a) For simple precision (32 bits), set sign = 0/1, mantis = 0x7FFFFF, exponent = 0xFF, and you get +/-INF.
b) Similar for double and extended precision.
This is how you set a NaN in simple precision:
Any number except +/-INF above, that has exponent = 0 or 0xFF is a NaN.
Gheorghe
|
|
|
|
|
|
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!
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#[^]!
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!
|
|
|
|
|
To my mind, the only reasonable operations with NaN are assigning an lvalue to NaN and comparing a value to NaN for equality and inequality. Any of the arithmetic operators ought to yield NaN (or throw an exception).
Come to think of it, the IEEE must have a formal document that describes all of this behavior. Pardon me while I JFGI... Ahh; typical. The formal document is only available to IEEE members who know the official circle jerk handshake. NaN - Wikipedia, the free encyclopedia[^] is a quick article that describes background and informally NaN's usage.
This article: IEEE Standard 754 Floating-Point[^] also has some discussion on NaN behavior.
Software Zen: delete this;
|
|
|
|
|
Sander Rossel wrote: Yes you can, and that's the point. Then be prepared to accept the consequences.
|
|
|
|
|
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.
|
|
|
|
|
And with that the case is more than closed.
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
|
|
|
|
|
More to the point, infinity is not a number.
|
|
|
|
|
Interesting; imho that implies the treatment of double.NaN in the 'Min function is different than in the 'Max function.
I am relieved to know that in .NET C# double.PositiveInfinity == double.NegativeInfinity => 'false, since, if that returned 'true, I would assume my system is now a conscious entity ... in which case it would certainly be planning to kill me in league with the various cpu's in my home appliances.
Be careful, Sander, it was the contemplation of the mathematics of the ordinality of infinities (the aleph) that drove both Cantor, and Godel, insane.
cheers, Bill
«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
|
|
|
|
|
....which, of course, is the crux of how the Total Perspective Vortex operates.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
BillWoodruff wrote: that implies the treatment of double.NaN in the 'Min function is different than in the 'Max function Actually, it doesn't. Both Min and Max treat NaN as the smallest value.
However, when comparing NaN to any other value it's both bigger and smaller.
BillWoodruff wrote: it was the contemplation of the mathematics of the ordinality of infinities (the aleph) that drove both Cantor, and Godel, insane It was mathematics that drove me insane in high school . And then again at University. And then again at another University...
|
|
|
|
|
BillWoodruff wrote: that implies the treatment of double.NaN in the 'Min function is different than in the 'Max function.
I doubt it there is different treatment, it's just different implementation of if condition. For instance, Min method could have this condition:
if (currentMin > values[i])
currentMin = values[i];
and Max this one:
if (!(currentMax > values[i]))
currentMax = values[i];
If Max was implemented in this way:
if (currentMax < values[i])
currentMax = values[i];
it would return NaN also.
edit:
I'll be damned. NaN indeed has different treatment in Min method. Comment from the source code[^]:
if (x < value || System.Single.IsNaN(x)) value = x;
modified 2-Oct-16 17:01pm.
|
|
|
|
|
Mladen Janković wrote: I'll be damned. NaN indeed has different treatment Oh my, are you saying that my post actually meant something ? If that's the case, I hereby offer you enough plenary indulgence to be un-damned ... once you have voted.
«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
|
|
|
|
|
Mmm, naan bread, just like granny used to make.
veni bibi saltavi
|
|
|
|
|
In WPF you can set the width of certain visual components to Double.NaN. This is interpreted by .NET to mean "width is set to auto".
At least that is how I remember the use for Double.NaN
Get me coffee and no one gets hurt!
modified 2-Oct-16 17:29pm.
|
|
|
|
|
I guess "Auto" would be one example of NaN
|
|
|
|
|
Comparing a floating point value with NaN always returns false (an "unordered result"; even when both operands are NaN).
This can be seen at your 3rd test. With the Min() code, all values are checked if they are smaller than the others. Because comparing with NaN is always false, no other element is detected as smaller and the check retunrs NaN. With the Max() code the values are compared to be greater which always fails for NaN.
See also NaN - Wikipedia, the free encyclopedia[^].
|
|
|
|
|
So it's completely dependent on the internals of Min and Max.
Had Max checked if any values were smaller than the current then NaN would always be max and had Min checked if any values were greater than the current then NaN would never be min.
So change your implementation and NaN will behave differently, feels very random.
|
|
|
|