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
www.cs.berkeley.edu/~ejr/Projects/ieee754/meeting-minutes/02-11-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.

In article <1156727969.608759.80730@m73g2000cwd.googlegroups.com>,
norb1@yahoo.com writes:

Why?

Don't take this the wrong way. But, the members of the IEEE754
committee probably have much more experience than you (and
many of the people here in c.l.f) in floating point mathematics.
If they came to the conclusion that

"There is no mathematical reason to prefer one reason to another."

then you may want to pay attention to them, and guard against
suspect comparisons.

Hello,

Steven G. Kargl wrote:

Note that this is true, *even if the x/y were an argument
of the max()*.

The compiler must evaluate the values of the arguments,
next associate the values with the dummy arguments,
next call the function.

"History is just one damn thing after another." :-)

norb1@yahoo.com wrote:

A standard-conforming Fortran processor is allowed to evaluate
max(x,y) as

if(x > y) then
max = x
else
max = y
endif

If x is NaN, then x > y is unordered (i.e., it is not true in IEEE
arithmetic).
The ELSE branch is taken, so max(NaN,0.0) = 0.0.

--Eric

norb1@yahoo.com wrote:

In article <1156727969.608759.80730@m73g2000cwd.googlegroups.com>,
norb1@yahoo.com wrote:

But by your argument, the convention Max(NaN,0.)=NaN would be wrong
the other half. That is probably why they concluded

"There is no mathematical reason to prefer one reason to another."

$.02 -Ron Shepard

Ron Shepard wrote:

--------------------------------------------
Kahan proposed two mathematical characterizations for max over the
reals plus points at +/-inf which can be extended to NaNs:

1. z := Max{x, y} iff z <= x or z <= y
2. z := Max{x, y} iff z >= x and z >= y

Using the first definition, Max{5, NaN} = 5. Under the second
definition, Max{5, NaN} = NaN. There is no mathematical reason to
prefer one reason to another.

In article <1156734621.572922.27910@m79g2000cwm.googlegroups.com>,
ejko123@yahoo.com says...

Is that how max is defined by the standard? if not, if your
processor instead evaluates max(x,y) as