|laziness, impatience, and hubris|
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.
For that program, my 8.0 MS compiler outputs:
but my gcc-4.5.2 produces:
Which one is doing it correctly ?
What operations will result in a signalling nan ?
In reply to Re: Exploring IEEE754 floating point bit patterns.