Re: Exploring IEEE754 floating point bit patterns.

[syphilis]

Very interesting stuff.
They now provide 5 separate symbols for a nan - negative and positive versions of both the signalling and non-signalling nan, plus an extra one (-1.#IND) just in case you are not already sufficiently confused.
Actually, make that 10 separate symbols, as the 5 nan symbols that appear in the output of BrowserUk's qnan.c, under some circumstances, will be suffixed with '0' ('00' in the case of -1.#IND).

I wonder why so many symbols are needed ?
Just one nan symbol would be enough for me - as it is (eg)for the mpfr library.

It's also interesting that,of my Microsoft compilers (6.0, 7.0 and 8.0), none of them produce the same output as BrowserUk's 9.0 compiler.
My 8.0 comes closest - the only discrepancy being that it outputs '0' for negative zero instead of '-0'.
My 6.0 and 7.0 compilers also display negative zero as '0'. Additionally they don't provide the 1.#SNAN symbols - choosing to show them as 1.#QNAN instead, and designating all of the nans as "quiet" nans.

My gcc (MinGW) compilers (versions 3.4.5, 4.5.2 and 4.7.0) all do the right thing with negative zero but it's only 4.7.0 that goes to the trouble of providing the 1.#SNAN signalling nans.

It's a pity that the consistency is lacking - but the real puzzle for me is how to predict which of the various 'nans' will be produced by a specific operation.

An example:

#include <stdio.h>
#include <math.h>

int main(void) {
    double x = 1.0;
    double y = 0.0;
    double inf = x /y;
    printf("%f %f\n", inf / inf, -(inf / inf));

    return 0;
}

For that program, my 8.0 MS compiler outputs:
-1.#IND00 -1.#IND00

but my gcc-4.5.2 produces:
-1.#IND00 1.#QNAN0

Which one is doing it correctly ?

What operations will result in a signalling nan ?

Cheers
Rob

[BrowserUk]

Actually, make that 10 separate symbols, as the 5 nan symbols that appear in the output of BrowserUk's qnan.c, under some circumstances, will be suffixed with '0' ('00' in the case of -1.#IND).I wonder why so many symbols are needed ?

The suffixing of zeros to the symbols is just an artifact of using "%f" printf format, which implicitly is equivalent to "%.6f" and therefore requires that the fractional part be padded with trailing zeros to 6 places.

If you adjust the template, you can see this. (The printf from your code above + output):

    printf("%f %f\n",       inf / inf, -(inf / inf)); // -1.#IND00 -1.
+#IND00
    printf("%.4f %.4f\n",   inf / inf, -(inf / inf)); // -1.#IND -1.#I
+ND
    printf("%.10f %.10f\n", inf / inf, -(inf / inf)); // -1.#IND000000
+ -1.#IND000000

I've found %g more useful:

    printf("%g %g\n", inf / inf, -(inf / inf));      // -1.#IND -1.#IN
+D

It's also interesting that,of my Microsoft compilers (6.0, 7.0 and 8.0), none of them produce the same output as BrowserUk's 9.0 compiler.

The changes are (roughly) in line with the timing of the compiler releases relative to the requirements of the various ANSI C standards C89/C90/C99/C11; and as affected by the updates to the IEEE754 (1987) standard and its revision in 2004. (Roughly:)

For that program, my 8.0 MS compiler outputs: -1.#IND00 -1.#IND00 but my gcc-4.5.2 produces: -1.#IND00 1.#QNAN0 Which one is doing it correctly ?

You'll hate this answer. Effectively, they both are!.

The problem is, the computer scientists and the mathematicians can't agree on a single Function definition with respect to FP math.

The problem is two-fold:

1. FP math isn't like real math (Real in the mathematical sense).

   Eg. FP is not always associative:

   print +( 10.0**20 + 1 ) - 10.0**20;;
   0
   
   print +( 10.0**20 - 10.0**20 ) + 1;;
   1
   

2. Mathematicians have conventions for the results of some operations that don't quite work arithmetically.

   Eg. infinity**0 == 1!

   These allow their operations on the continuous Real domain to avoid singularity points

You pays your money and makes your choice.

What operations will result in a signalling nan ?

From what I've been able to discover, none of them! (At least as far as MSC v9 is concerned.)

The problem here is that the IEEE-754 allows for traps, but doesn't require them. See Signaling NaNs

My take on what I see coming out of my attempts to produce NaNs with MSC(v9), is that they settled on using -1.#IND as the result of any math operation that is (for want of a better phrase) 'not well defined'. eg. sqrt( -1 ), 0/0; fmod( 1, 0 ) etc.

[syphilis]

BrowserUk, many thanks for this thread.
I'm currently trying to make sense of what happens wrt a PDL test script (t/pdl_from_string.t) on MS Windows, and this has helped enormously.

I now have a clear view of what needs to be done.

Cheers,
Rob