max(NaN,0) should be NaN

[Michel Hack]

There is at least one good reason for the current standard behavior:

It maintains the maximum amount of information.
...

OTOH there is an equally good reason for requiring the opposite
behavior, i.e. max(...) is NaN if any input value is NaN:

This is why 754R specifies two separate functions, max() and maxnum()
(and similarly for min() , maxmag() and minmag()).

Michel.

 

[Michel Hack]

|>
|> OTOH, having a standard which requires silent removal of NaNs _is_ a
|> problem. :-(

I quite agree. C99 Annex F - just say "no".

Both of you should have participated in the 754R discussions, which are
winding down now -- but the official IEEE ballotting will start later
this year, and perhaps you should join the IEEE SA (Standards
Association) if you have not done so already (deadline Sept 28), so you
can comment when the draft is published for review in a month or so.

The standard deliberately avoids assigning meaning to NaN payloads, but
from various discussions about the distinction between "missing data"
and "invalid data" it seems to me that defining a particular NaNcode
(other than the machine default) for "missing" would have been quite
valuable. I'm just afraid of bringing it up so late in the game...


Interestingly IBM's "High Level Assembler" does support defining two
kinds of quiet NaN in floating-point constants: (NAN) implies machine
default (double 0x7ff80000...) and (QNAN) implies 0x7ffc0000... but I
don't know of any software that exploits this.

Michel.