What the NaN?

Mladen Jankovic

Sander Rossel wrote:

why would there even be a NaN anyway...

0/0
∞/∞
∞+(-∞)
√-1
and so on...

Just because you are not familiar with the subject, does not make others wrong.

GeoGame for Windows Phone | The Lounge Explained In 5 Minutes

Mladen Jankovic

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[^]:

// Normally NaN < anything is false, as is anything < NaN
// However, this leads to some irksome outcomes in Min and Max.
// If we use those semantics then Min(NaN, 5.0) is NaN, but
// Min(5.0, NaN) is 5.0! To fix this, we impose a total
// ordering where NaN is smaller than every value, including
// negative infinity.
if (x < value || System.Single.IsNaN(x)) value = x;

GeoGame for Windows Phone | The Lounge Explained In 5 Minutes

Sander Rossel

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

Jochen Arndt

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[^].

Mladen Jankovic

I would recommend you to this article before you continue your rant about IEEE754.

GeoGame for Windows Phone | The Lounge Explained In 5 Minutes

Sander Rossel

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.

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

Lost User

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).

Mladen Jankovic

Here's the reasoning from the source code[^]:

                // Normally NaN < anything is false, as is anything < NaN
                // However, this leads to some irksome outcomes in Min and Max.
                // If we use those semantics then Min(NaN, 5.0) is NaN, but
                // Min(5.0, NaN) is 5.0!  To fix this, we impose a total
                // ordering where NaN is smaller than every value, including
                // negative infinity.

GeoGame for Windows Phone | The Lounge Explained In 5 Minutes

Sander Rossel

Tried to read it once, but to me it makes as much sense as the whole NaN implementation: none whatsoever (and I admit my limited math skills are to blame). However, I tried reading the NaN part and what they basically say is that in some edge cases you don't want computations to stop (throw exceptions) when some bogus values are inserted (e.g. divide by 0). The workaround without NaN would be to catch exceptions and simply try again. Unfortunately, every language handles exceptions differently so they standardized on NaN. Awesome, they destroyed our numeric system to support some edge cases (correct me if I'm wrong) :D Luckily .NET offers some sensible numeric types with int, long and decimal :D Unfortunately, I'm currently working in JavaScript, with floating point arithmetic, where NaN is quite common, and 0.1 + 0.2 equals 0.30000000000000004 (yes, I know that's IEEE754, but that doesn't make it right) :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

Thanks, good find! At least that clears that up! :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

Sander Rossel

By the way, the email for this message had a YouTube link attached to it. I just found it in your sig :laugh: And I would once again argue that the existence of NaN is just plain wrong. Well, at least you're right about the Lounge ;p

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

BillWoodruff

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

Gary R Wheeler

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;

Super Lloyd

Did you know that both 1 < double.NaN and 1 > double.NaN are false?! ;P

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

BillWoodruff

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

Mladen Jankovic

Sander Rossel wrote:

they destroyed our numeric system to support some edge cases

Any representation of real numbers in computer memory will destroy 'numeric system' since you're trying to represent infinite set with finite amount of memory.

Sander Rossel wrote:

Luckily .NET offers some sensible numeric types with int, long and decimal :-D

decimal comes with performance costs as it has no support in hardware so it might not be suitable as a replacement in fields that traditionally use floating point arithmetic. It is meant to be used for financial stuff since IEEE754 is not suitable for that purpose, so not everyone have to invent their own way of doing math.

Sander Rossel wrote:

0.1 + 0.2 equals 0.30000000000000004

That's the problem with converting real numbers between different bases.

GeoGame for Windows Phone | The Lounge Explained In 5 Minutes

Mladen Jankovic

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 :)

GeoGame for Windows Phone | The Lounge Explained In 5 Minutes

Jochen Arndt

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).

BillWoodruff

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

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