473,899 Members | 4,012 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

max(NaN,0) should be NaN

After tracking down a bug in my Fortran program, I found that it
assumed
max(NaN,0.) = 0.

This makes no sense, as the outcome of the operation is undefined and
should be NaN.
max(NaN,0.) = NaN

After researching, it appears the first outcome is accepted behavior,
and might be included in the revised IEEE 754 standard, which affects
not only Fortran. The discussion posted at
http://www.cs.berkeley.edu/~ejr/Proj...21.html#minmax
suggests that "There is no mathematical reason to prefer one reason to
another."

But I think otherwise, for the following reason. Suppose the NaN is
produced by x/y, where x=0 came from an underflow and y=0 came from an
underflow. Then x/y would be a well-defined number that could be
postive or negative. The convetion max(NaN,0.) = 0. is wrong at least
half the time.

Aug 28 '06
61 8695

Terje Mathisen wrote:
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.

Sep 8 '06 #61

Nick Maclaren wrote:
In article <kt************ @osl016lin.hda. hydro.com>,
Terje Mathisen <te************ @hda.hydro.comw rites:
|>
|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.

Sep 8 '06 #62

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.