max（NaN，0）应为NaN [英] max(NaN,0) should be NaN

问题描述

在追踪我的Fortran程序中的一个错误之后，我发现它是假定的b
$ b最大值（NaN，0。）= 0.


这没有任何意义，因为操作的结果是未定义的并且

应该是NaN。

max（NaN，0。）= NaN


经过研究，看来第一个结果是接受的行为，

并且可能包含在修订的IEEE 754标准中，这影响了

不仅是Fortran。讨论发布在
http://www.cs.berkeley.edu/~ejr/Proj...21.html#minmax

表示没有数学上有理由更喜欢一个理由而是另一个原因。

但我认为不然，原因如下。假设NaN是由x / y产生的
，其中x = 0来自下溢，y = 0来自

下溢。然后x / y将是一个明确定义的数字，可能是b
postive或negative。对流最大值（NaN，0。）= 0是错误的，至少是b $ b的一半时间。

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.

推荐答案

< no *** @ yahoo.comwrote in message

news：11 ********************* @ m73g2000cwd。 googlegro ups.com ...

<no***@yahoo.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...

在追踪我的Fortran程序中的一个错误之后，我发现它已经假定为b $ b假设

max（NaN，0。）= 0.


这没有任何意义，因为操作的结果是未定义的并且

应该是NaN。

max（NaN，0。）= NaN


经过研究，看来第一个结果是接受的行为，

并且可能包含在修订后的IEEE 754标准中，该标准不仅影响了Fortran的
。讨论发布在
http://www.cs.berkeley.edu/~ejr/Proj...21.html#minmax

表示没有数学上有理由更喜欢一个理由而是另一个原因。

但我认为不然，原因如下。假设NaN是由x / y产生的
，其中x = 0来自下溢，y = 0来自

下溢。然后x / y将是一个明确定义的数字，可能是b
postive或negative。对流最大值（NaN，0。）= 0是错误的，至少是b $ b的一半时间。

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.

我同意你的观点，但遗憾的是，有一种想法是

*有时* NaN表示没有候选值。 。根据这个逻辑，两个或更多值的最大值b / b仅仅省略了NaN作为竞争者。 Yuk。


PJ Plauger

Dinkumware，Ltd。
http://www.dinkumware.com

文章< 11 ********* ************@m73g2000cwd.googlegroups。 com>，
no***@yahoo.com 写道：

In article <11*********************@m73g2000cwd.googlegroups. com>,
no***@yahoo.com writes:

这没有任何意义，因为操作的结果是未定义的并且

应该是NaN。

max（NaN，0。）= NaN

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

为什么？

Why?

经过研究，看来第一个结果是接受的行为，

并且可能包含在修订后的IEEE 754标准中，该标准不仅影响了Fortran的
。讨论发布在
http://www.cs.berkeley.edu/~ejr/Proj...21.html#minmax

表示没有数学上有理由倾向于另一个原因。
另一个原因。

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

不要采取错误的方式。但是，IEEE754

委员会的成员在浮点数学方面可能比你（和许多人在clf中的许多人）拥有更多的经验。

如果他们得出结论


没有数学上的理由偏好一个理由到另一个理由。


那么你可能要注意它们，并防范

怀疑比较。

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.

但我认为不然，原因如下。假设NaN是由x / y产生的
，其中x = 0来自下溢，y = 0来自

下溢。然后x / y将是一个明确定义的数字，可能是b
postive或negative。对流最大值（NaN，0。）= 0是错误的，至少是b $ b的一半时间。

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没有滞后现象。它不知道

或者关心你如何得x = 0和y = 0.所有它试图

do是评估x / y。这是一个NaN。


-

Steve
http://troutmask.apl.washington.edu/~kargl/

您好，


Steven G. Kargl写道：


< snip>

Hello,

Steven G. Kargl wrote:

<snip>

AFAIK，Fortran没有滞后现象。它不知道

或者关心你如何得x = 0和y = 0.所有它试图

do是评估x / y。这是一个NaN。

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.

注意这是真的，*即使x / y是一个参数

的max（）*。


编译器必须评估参数的值，

接下来将值与伪参数相关联，

接下来调用函数。 br />

历史只是一个又一个该死的东西。 :-)


-

干杯！


Dan Nagle

紫色Sage Computing Solutions，Inc。

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.

这篇关于max（NaN，0）应为NaN的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！