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. 61 8696
<no***@yahoo.co mwrote in message
news:11******** *************@m 73g2000cwd.goog legroups.com...
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.
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
In article <11************ *********@m73g2 000cwd.googlegr oups.com>, no***@yahoo.com writes:
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 http://www.cs.berkeley.edu/~ejr/Proj...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.
--
Steve http://troutmask.apl.washington.edu/~kargl/
Hello,
Steven G. Kargl wrote:
<snip>
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." :-)
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc. no***@yahoo.com wrote:
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 no***@yahoo.com wrote:
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."
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.
In article <11************ *********@m73g2 000cwd.googlegr oups.com>, no***@yahoo.com wrote:
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
Ron Shepard wrote:
In article <11************ *********@m73g2 000cwd.googlegr oups.com>, no***@yahoo.com wrote:
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.
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.
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." From the above minutes:
--------------------------------------------
Kahan proposed two mathematical characterizatio ns 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.
---------------------------------------------
I don't understand 1. - doesn't look like a correct Max definition to
me (even if the missing "z belongs to {x,y}" is added).
Jaroslav
In article <11************ *********@m79g2 000cwm.googlegr oups.com>, ej*****@yahoo.c om says...
[...]
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.
--
Christer Ericson http://realtimecollisiondetection.net/ This thread has been closed and replies have been disabled. Please start a new discussion. | |