|
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.
|
|
|
|
|
Sander Rossel wrote: NaN will behave differently, feels very random.
Sander, this is a brilliant idea you've come up with; I'll offer a quick sketch, and look forward to your comprehensive implementation:
namespace CatState
{
public static class CatStateExtensions
{
public static double CatDead(this double[] args)
{
if (args.Contains(double.NaN))
{
Random rnd = new Random((int) DateTime.Now.Ticks);
return (rnd.Next(0,2) == 0)
? double.PositiveInfinity
: double.NegativeInfinity;
}
return args.Min();
}
public static double CatAlive(this double[] args)
{
if (args.Contains(double.NaN))
{
Random rnd = new Random((int) DateTime.Now.Ticks);
return (rnd.Next(0,2) == 1)
? double.PositiveInfinity
: double.NegativeInfinity;
}
return args.Max();
}
}
}The half-dead cats fighting over half-dead fish-heads have been keeping me up nights, lately.
«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: Random rnd = new Random((int) DateTime.Now.Ticks);
Reseeding RNG each time you make a call with nothing more than current time as a source of randomness, that's just a disaster waiting to happen. Output of your methods would be easily predictable. Nobody want their Schrödinger's cat predictable 
|
|
|
|
|
Hi Mladen,
DateTime.Now.Ticks "is the number of 100-nanosecond intervals that have elapsed since 1/1/0001, 12:00am."
Yes: if you had a loop calling that function faster than 100 ns., you could get a duplicate seed, and what you suggest is better practice.
If "heavier-duty randomness" were required I would use the Crypto library.
In real-world code, I would create a single static instance of 'Random, and re-use it.
I wrote that code while I was half-dead, although that's a very poor excuse
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
|
|
|
|
|
BillWoodruff wrote: I wrote that code while I was half-dead, although that's a very poor excuse
Not if you're actually Schrödinger's Bill! 
|
|
|
|
|
The behaviour of comparing with Nan is defined.
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
Overall, comparing with NaN makes no sense as already noted by others. Just change the order of your elements (e.g. NaN as first element).
|
|
|
|
|
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 
|
|
|
|
|
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).
|
|
|
|
|
I can sort of see how that might happen, but I would prefer Min and Max ignored the NaN unless they had no choice (if it's the only thing in the list, there's no better choice).
|
|
|
|
|
|
Thanks, good find! At least that clears that up!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
