the phrase "(erroneous) floating point (NV) values" did catch my eye. I'm wondering why "(erroneous)" is in there.

1.#INF means 'greater than the floating point representation can hold". Ie. Floating point overflow.

See If your operation would generate a larger positive number than could be stored in a double, the operation will return 1.#INF on Windows or inf on Linux. Similarly your code will return -1.#INF or -inf if the result would be a negative number too large to store in a double.

Ie. #INF is a 'floating point exception'. 'Exception is variously defined as: anomaly, irregularity, deviation, special case, departure, inconsistency, quirk, peculiarity, abnormality, oddity;.

Ie. A value beyond the capabilities of the binary format to represent. Ie. an erroneousness value.

Ie. A value beyond the capabilities of the binary format to represent. Ie. an erroneousness value.

Hmmm ... "erroneous" is not a term that I would normally use here. However, it could be handy for some leverage at some stage, so I'll keep it in mind.

Interestingly, by my reading of Wikipedia, underflow (when the result of a calculation is a smaller number than the computer can actually store in memory) is also an exception in IEEE 754.
So it, too, pertains to "a value beyond the capabilities of the binary format to represent".

Maybe we'll see you referring to an "erroneous zero" at some time in the future ;-)

Cheers,
Rob

by my reading of Wikipedia, underflow ... is also an exception in IEEE 754. So it, too, pertains to "a value beyond the capabilities of the binary format to represent".

Maybe we'll see you referring to an "erroneous zero" at some time in the future ;-)

Hm. Did you ever see Edward Woodward in The Wicker Man? That was a bigger straw man, but not by much :)

An "erroneous zero"? No. A value of zero erroneously produced when underflow occurs, yes.

And if you override the run-time's dubious default setting of 'ignoring floating point exceptions', it can even be detected and handled:

#define _CRT_SECURE_NO_WARNINGS 1
#include <stdio.h>
#include <float.h>
#include <excpt.h>

int main( int argc, char **argv ) {
    unsigned int  u = _controlfp(0, 0);
    double x = 0.5e-323, y = 0.5e-323;

    printf( "x contains: %g before dividing by 2\n", x );
    x /= 2;
    printf( "x now contains: %g\n", x );

    u = u & ~_EM_UNDERFLOW;
    _controlfp(u, _MCW_EM);

    printf( "\ny contains: %g before dividing by 2\n", y );
    __try {
        y /= 2;
    }
    __except( EXCEPTION_EXECUTE_HANDLER ) {
        printf( "Floating point underflow exception occurred\n");
    }
    printf( "y now contains: %g\n", y );
    return 0;
}
[download]

So whilst the value zero isn't erroneous; a variable can acquire the value zero erroneously:

C:\test>intOverflow.exe
x contains: 4.94066e-324 before dividing by 2
x now contains: 0

y contains: 4.94066e-324 before dividing by 2
Floating point underflow exception occurred
y now contains: 4.94066e-324
[download]

Is this going anywhere?

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.