NaNs Just Don't Get No Respect(drdobbs.com) |
NaNs Just Don't Get No Respect(drdobbs.com) |
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 ramifications in real code, but it certainly makes things less elegant and more complex than they have to be.
However, you should be able to examine two NaNs and declare them "equivalent" (for certain definitions of equivalence) by intelligently examining the bits based on the hardware that you're running the program on. In the case of a binary Nan [1] that would entail checking that the exponential fields are both entirely high (eg 0x8 == (a.exponent & b.exponent), assuming a standard 8 bit exponent) and that the mantissas are nonzero (eg a.mantissa && b.mantissa).
[1]: "Binary format NaNs are represented with the exponential field filled with ones (like infinity values), and some non-zero number in the significand (to make them distinct from infinity values)." --http://en.wikipedia.org/wiki/NaN
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;
I wish all languages would have nullability like SQL does. Where a great care has to be given to deal with nullable data, lest nulls nullify everything.
I guess one option would be to just declare that all NaNs are equal--I'm pretty sure that's how bottoms work in Haskell, and it seems that NaN is essentially a floating-point version of bottom.
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.
They're also a sign you're skirting on the limits of FP precision (or worse) so a bit of numerical analysis might still be a good idea...
EDIT: I do not know how D implements NaNs; they may have magic to make them more sane to work with.
What D does do is expose NaNs so the programmer can rely on their existence and use them in a straightforward manner.
float f;
bool thingIsFoo = condition1; // store the result…
if (thingIsFoo)
f = 7;
// ... code ...
if (thingIsFoo && condition2) // and explicitly depend on it later
++f;
Gee, thanks MSC. I didn't expect "x = INFINITY;" to overflow.
Also check the flags, like /fp:precise for MSVC
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).
This is somewhat simpler--as long as either argument to (==) is NaN the answer is False. However, you still have to figure out that at least one bit pattern corresponds to NaN. If you want them to be equal, you would have to figure out that both are NaN. This is certainly a little more difficult, but I think it isn't much worse than the current scenario.
For example:
float a = 1.0;
float b = 1000.0;
for (int i = 0; i < 1000000; ++i)
a+=1.0;
b *= b;
What do you mean by
algorithms that are more reliably written not to contain any empty intervals are two examples.> What do you mean by
I mean exactly that sort of thing. Algorithms that, for example, divide a line into intervals, where empty intervals are not needed, or desired, and are generally risky with respect to the probability of having a correct implementation. An example of this would be computations of the area of a union of rectangles. You might make a segment tree -- and avoid having degenerate rectangles in your segment tree.
float a = 0.0;
float b = 10000.0;
for (int i = 0; i < 100000000; ++i)
a+=1.0;
b *= b;
and what happens when you go beyond 24 bits? since it's a float no error or warning will be thrown, but now equivalence won't work for numbers that are easily stored by an int.
Where did I say I'd use floating point numbers for integer math? Yes, let's move the conversation to a direction it never existed so that you can pretend you were right.
(The place I'd use it would be in a Javascript implementation, or a Lua implementation, and other situations where I'm designing a programming language where I want the simplicity of having only one numerical type. And that would be a 53-bit range, not 24-bit.)
I've not used lua or javascript, but wouldn't it be better to choose an implmentation that silently switches between ints, floats, doubles and big-nums as needed? That way you don't limit the speed float and int operations by autoconverting up to doubles, when double precision isn't needed.
> I've not used lua or javascript, but wouldn't it be better to choose an implmentation that silently switches between ints, floats, doubles and big-nums as needed?
If you want to go through the engineering effort, sure, it might make sense to have separate int and double encodings. You have to check for the possibility of integer overflow and convert to double in that case. In particular, this is useful if you want to use Javascript's bitwise operators. See https://developer.mozilla.org/en-US/docs/SpiderMonkey/Intern... for a description of how SpiderMonkey does it. Lua just has one representation for numbers, double normally but it could be float or long depending on how you compile it. There would be no reason to have single-precision floating point or big-num representations.