max(NaN,0) should be NaN

[norb1]

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.

 

[P.J. Plauger]

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.

I agree with you, but unfortunately there's a school of thought that
*sometimes* NaN means "no candidate value". By this logic, the maximum
of two or more values simply omits NaNs as contenders. Yuk.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Steven G. Kargl]

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

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."

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.

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.

AFAIK, Fortran does not have hysteresis. It does not know
or care how you got to x = 0 and y = 0. All it tries to
do is evaluate x/y. This is a NaN.

 

[Dan Nagle]

Hello,

Steven G. Kargl wrote:

AFAIK, Fortran does not have hysteresis. It does not know
or care how you got to x = 0 and y = 0. All it tries to
do is evaluate x/y. This is a NaN.

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."

 

[ejko123]

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

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

 

[Tim Prince]

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."

On a somewhat related question, a colleague and I have observed
evaluation of MAXVAL() or MINVAL() where certain versions of certain
compiler libraries ignore all array elements up to and including the
last NaN, while other libraries simply ignore all NaN values. We have
never observed NaN as a result. We haven't gathered visible support for
our request that a consistent position should be taken.

 

[Ron Shepard]

The convetion max(NaN,0.) = 0. is wrong at least
half the time.

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

 

[norb1]

But by your argument, the convention Max(NaN,0.)=NaN would be wrong
the other half.

Of course, NaN could always be a well-defined value, just as Inf can be
produced by an overflow of a finite number. Inf can represent a finite
number too large to fit in the exponent field (an inexact infinity so
to speak); NaN can represent any value, only the computer wasn't able
to figure out which one (an inexact NaN). Its meaning is not
restricted to being "not a real number", because it often results from
a combination of underflows and overflows that do not necessarily
correspond to exact zeros and exact infinities. In this sense,
max(NaN,0.) = NaN is always correct. Indeed, max(NaN,0.) is
occasionally correct. On the same basis one could suggest the sign of
NaN be negative, because this is occasionally correct.

 

[highegg]

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."
From the above minutes:

--------------------------------------------
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.

 

[Christer Ericson]

[...]
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.

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

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

the else-branch is still taken and now max(NaN,0.0) = NaN.
In this case your argument is in support of both results,
rendering the argument void.

 

[=?ISO-8859-15?Q?Jan_Vorbr=FCggen?=]

A standard-conforming Fortran processor is allowed to evaluate

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

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

the else-branch is still taken and now max(NaN,0.0) = NaN.
In this case your argument is in support of both results,
rendering the argument void.

And in any case, changing the order of the arguments would change the
result, in both cases. I do think it's imperative that max(a,b)==max(b,a).

Jan

 

[highegg]

And in any case, changing the order of the arguments would change the
result, in both cases. I do think it's imperative that max(a,b)==max(b,a).

Why? Other operations that are mathematically commutative lose this
property in floating point.

 

[=?ISO-8859-1?Q?Jan_Vorbr=FCggen?=]

And in any case, changing the order of the arguments would change the

Why? Other operations that are mathematically commutative lose this
property in floating point.

Which ones do? Associativity - yes, I see that. But commutation?

Jan

 

[Simon Biber]

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.

For what it's worth, the C standard makes it clear that fmax should
produce 0 in this case.

In the footnote to 7.12.12.2:
"NaN arguments are treated as missing data: if one argument is a NaN and
the other numeric, then the fmax functions choose the numeric value. See
F.9.9.2."

Normative appendix F.9.9.2 says, of implementations that define
__STDC_IEC_559__,
"If just one argument is a NaN, the fmax functions return the other
argument (if both arguments are NaNs, the functions return a NaN)."

 

[highegg]

Which ones do? Associativity - yes, I see that. But commutation?

OK, I cannot state this for sure, as I don't have access to the IEEE
standard,
but I was under the impression (perhaps until now you correct me) that,
if _mathematically_
a+b == (c + nearest(c,+1.))/2,
then you can have in FP
a+b == c
b+a == nearest(c,+1.)

and that more possibilities are allowed with more complex expressions
as a*b + c*d /= c*d + a*b

Jaroslav

 

[Terje Mathisen]

And in any case, changing the order of the arguments would change the
result, in both cases. I do think it's imperative that max(a,b)==max(b,a).

I agree that this is a good idea, acording to 'the principle of least
astonishment', but the problem here is that NaNs already break this in
various ways. I.e. they are defined (afair) to compare false against any
real number, which does mean that _both_

if (a > NaN) {}

and

if (a <= NaN) {}

should be false, i.e. as soon as you allow NaNs the normal rules for
logical operations break down completely. :-(

At least on x86/x87 hardware any comparison against NaN will return
'UNORDERED', which is distinct from the set of 'greater_than', 'equal',
'less_than'.

Terje

 

[=?ISO-8859-1?Q?Jan_Vorbr=FCggen?=]

I agree that this is a good idea, acording to 'the principle of least

astonishment', but the problem here is that NaNs already break this in
various ways. I.e. they are defined (afair) to compare false against any
real number, which does mean that _both_

if (a > NaN) {}

and

if (a <= NaN) {}

should be false, i.e. as soon as you allow NaNs the normal rules for
logical operations break down completely. :-(

No, no - you forgot to check for orderability beforehand. You wouldn't
expect this to work for, e.g., spinors (not to mention complex numbers),
would you?

At least on x86/x87 hardware any comparison against NaN will return
'UNORDERED', which is distinct from the set of 'greater_than', 'equal',
'less_than'.

And that is as it should be!

Jan

 

[=?ISO-8859-1?Q?Jan_Vorbr=FCggen?=]

OK, I cannot state this for sure, as I don't have access to the IEEE

standard,
but I was under the impression (perhaps until now you correct me) that,
if _mathematically_
a+b == (c + nearest(c,+1.))/2,
then you can have in FP
a+b == c
b+a == nearest(c,+1.)

I don't see anything in the algorithmic description of floating-point addition
that allows this kind of asymmetry. You shift the mantissas based on the
difference in exponent towards the larger value, add, and renormalize. All
of these operations are symmetrical in the operands.

Jan

 

[Dik T. Winter]

> I don't see anything in the algorithmic description of floating-point
> addition that allows this kind of asymmetry. You shift the mantissas
> based on the difference in exponent towards the larger value, add, and
> renormalize. All of these operations are symmetrical in the operands.

On the CDC Cyber 205, in a vector add the second operand was shifted
so that the exponents became equal. If a right shift, the shifted off
bits were lost, on a left shift everything was retained. And if the
left shift was too large, a short-cut was made. On tht machine, with
those operations, addition was not commutative.

 

[Richard E Maine]

On the CDC Cyber 205,... On tht machine, with
those operations, addition was not commutative.

Though I'd personally characterize the philosophy of the CDC machines of
that era as being that speed was more important than the last few bits
of accuracy. They counted on the 60-bit word to be enough to make up for
being "sloppy" about the last few bits.

I can't tell precisely what environment some posters in the thread are
talking about. I suspect different posters are talking about different
things without specifying so, which gets confusing. Some posters have
mentioned the IEEE standard, while others appear to be talking in more
general terms about any floating point implementation or about the
requirements of the Fortran (or C?) standard. I'm afraid that I can't
follow the result because I'm unsure what unstated assumptions apply to
each post. I can make guesses, but it is easy to guess incorrectly in
some cases. I'm occasionally left with the impression that some posters
might be a bit vague on the distinction, which might explain why I have
trouble telling exactly what they meant.