Be afraid of QNaN the Barbarian!
NaNs Just Don't Get No Respect
11–20 of 36 posts
Re: NaNs Just Don't Get No Respect
#12I've gotten a bit pissed at the Microsoft C compiler for (1) having no standard way to generate NaN or Infinity and (2) having a good enough static analyzer that if you generate one by casting, it emits a warning saying that your arithmetic overflows. Gee, thanks MSC. I didn't expect "x = INFINITY;" to overflow.
0/0 should be NaN,
1/0 should be +Infinity,
-1/0 should be -Infinity. (I haven't tried that in a while).
Also check the flags, like /fp:precise for MSVC
Re: NaNs Just Don't Get No Respect
#13NaNs are annoying because, thanks to them, equality on floating point numbers is not an equivalence relation. In particular, NaN /= NaN. This means that in Haskell, for example, you cannot really rely on the Eq class representing an equivalence relation. Code relying on the fact that x == x should be true for all x could not work as expected for floating point numbers. I don't know if this has any practical ramificat…
This looks very much like NULLs in the SQL world. A null (and NaN) is like an unknown. One can't compare unknowns because they are exactly that, unknown. Let's construct a language that on division on zero returns unknowns. a = 5 / 0; b = 10 / 0; Now, both a and b are set to unknown state. If one were to compare a to b, should the expectation be that they hold same value? I wish all languages would have nullability l…
In some languages, a, b would be +Infinity.
On top of my head I can't remember whether +Infity != +Infinity (have to write a test and see). For NaN's definitely.
Re: NaNs Just Don't Get No Respect
#14There are much worse thing than NaN's.
They are called denormals. These appear when dealing at the same time with lots of big numbers (very far away from 0) in operations with lots small numbers (close to 0).
In such cases the FPU (or whatever deals with fp numbers), switches to a format that could be very inefficient producing an order of magnitude slower operations.
For example when dealing with IIR filters in audio, your audio buffer might contain them. One of the solution is to have a white noise buffer somewhere (or couple of numbers) that are not denormalized and add with them - it would magically normalize again.
I'm not a guy dealing with "numerical stability" (usually these are physics, audio or any simualation engine programmers), but know this from simple experience.
Re: NaNs Just Don't Get No Respect
#15Earlier quoted context omitted.
This looks very much like NULLs in the SQL world. A null (and NaN) is like an unknown. One can't compare unknowns because they are exactly that, unknown. Let's construct a language that on division on zero returns unknowns. a = 5 / 0; b = 10 / 0; Now, both a and b are set to unknown state. If one were to compare a to b, should the expectation be that they hold same value? I wish all languages would have nullability l…
In some languages, a, b would be +Infinity. On top of my head I can't remember whether +Infity != +Infinity (have to write a test and see). For NaN's definitely.
One of those languages is JavaScript, so--assuming your browser supports JavaScript--you do have somewhere to test it :P.
The answer is that 5 / 0 is Infinity and (5 / 0) == (5 / 0), so it's all good :). Now, 0 / 0 is NaN and (0 / 0) != (0 / 0).
Re: NaNs Just Don't Get No Respect
#16NaNs are annoying because, thanks to them, equality on floating point numbers is not an equivalence relation. In particular, NaN /= NaN. This means that in Haskell, for example, you cannot really rely on the Eq class representing an equivalence relation. Code relying on the fact that x == x should be true for all x could not work as expected for floating point numbers. I don't know if this has any practical ramificat…
Attmepting to just use simple equivalence with any floating point type a horrible idea to begin with, even without NaNs. You should instead declare equivalence if the absolute difference between the two numbers is less than some bound based on what you're doing and not look for bit equivalency. However, you should be able to examine two NaNs and declare them "equivalent" (for certain definitions of equivalence) by in…
That's not true, there are plenty of cases where using equivalence is just fine. Integer arithmetic, and algorithms that are more reliably written not to contain any empty intervals are two examples.
Re: NaNs Just Don't Get No Respect
#17Earlier quoted context omitted.
Attmepting to just use simple equivalence with any floating point type a horrible idea to begin with, even without NaNs. You should instead declare equivalence if the absolute difference between the two numbers is less than some bound based on what you're doing and not look for bit equivalency. However, you should be able to examine two NaNs and declare them "equivalent" (for certain definitions of equivalence) by in…
That's not true, there are plenty of cases where using equivalence is just fine. Integer arithmetic, and algorithms that are more reliably written not to contain any empty intervals are two examples.
He was specifically talking about equivalence on floating point types. Integers don't have or need NaN.
Re: NaNs Just Don't Get No Respect
#18Earlier quoted context omitted.
That's not true, there are plenty of cases where using equivalence is just fine. Integer arithmetic, and algorithms that are more reliably written not to contain any empty intervals are two examples.
He was specifically talking about equivalence on floating point types. Integers don't have or need NaN.
I was talking about integer values (with floating point representation) being multiplied and added (and divided and floored, I suppose).
Re: NaNs Just Don't Get No Respect
#19Stop trying to make D happen. It's not going to happen.
Re: NaNs Just Don't Get No Respect
#20The things this author likes about NaN are also properties of NULL in many environments (that NULL cannot be compared to NULL, that operating on NULL returns NULL, etc.); so while you might not see many languages default initializing things to NaN, you do see them default initializing things to NULL with similar effect.