|
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!
|
|
|
|
|
By the way, the email for this message had a YouTube link attached to it. I just found it in your sig 
And I would once again argue that the existence of NaN is just plain wrong.
Well, at least you're right about the Lounge 
|
|
|
|
|
Did you know that both 1 < double.NaN and 1 > double.NaN are false?!
|
|
|
|
|
I thought Julian Assange had called off his latest announcement of new WikiLeak content: [^].
Revelations like this, calling into question the entire structure of the way we view reality and the code tools we use to model it, is going to really shake things up.
The thought of the vast infinite hordes that NaN could mobilize and unleash on Primes and NotPrimes and SubPrimes ... frightening. I'm going to start building my bunker, now.
«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
|
|
|
|
|
Doom is upon us!
Or will be anytime soon now! 
|
|
|
|
|
I know, which makes its behavior in Min and Max even more random 
Although, as it turns out, it's not random at all. Min and Max just treat NaN as lower than anything else.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
