关于零的奇怪数值行为 [英] Weird numerical behavior regarding zero

问题描述

我目前正在使用修改后的单纯形法实现线性优化问题求解器

我偶然发现了一些奇怪的事情

关于数字0处理的行为。

我不确定这是编译器还是语言相关。


第一个问题是，有两个零的表示，即

+0和-0。 IEEE浮点数是否允许这样做？也许我没有
激活IEEE浮点数？

无论如何，这确实有一些非常烦人的后果，因为这个

表达式：

x / -0收益率-inf（x为正数）。


这让我想到了第二个问题。难道不能零除零件吗

我的电脑大火了吗？因为，在我的系统（Arch Linux 0.7

i686）上使用我的编译器（g ++ 3.4.3），允许除以零。

实际上，它产生+ inf当除以+ 0和-inf除以

-0时，鉴于提名者（英语术语为Z？hler？）是

当然是肯定的。


有什么意见/想法吗？


问候，

马蒂亚斯

解决方案

" matthias_k" <无**** @ digitalraid.com>在消息中写道

新闻：ct ************* @ news.t-online.com ...

第一个问题是，有两个零表示，即
+0和-0。 IEEE浮点数是否允许这样做？也许我没有激活IEEE浮点数？


IEEE浮点需要+0和-0作为不同的表示。

无论如何，这确实有一些非常令人讨厌的后果，因为这个
表达式：
x / -0收益率-inf（x为正数）。


是的，这就是IEEE浮点所需要的。

这让我想到了第二个问题。难道不能将零除以使我的计算机火上浇油吗？因为，在我的系统（Arch Linux 0.7
i686）上使用我的编译器（g ++ 3.4.3），允许除以零。

C ++说除以零之后发生的事情是未定义的。


IEEE表示结果是浮点陷阱或

适当签名无穷大，具体取决于方式你已经设定好了。


根据

IEEE

Andrew Koenig写道：

" matthias_k" <无**** @ digitalraid.com>在消息中写道
新闻：ct ************* @ news.t-online.com ...

第一个问题是，有两个零表示，即
+0和-0。 IEEE浮点数是否允许这样做？也许我没有激活IEEE浮点数？

IEEE浮点需要+0和-0作为不同的表示。

< blockquote class =post_quotes>无论如何，这确实有一些令人讨厌的后果，因为这个表达式：
x / -0产生-inf（x是正数）。

是的，这就是IEEE浮点所需要的。

这让我想到了第二个问题。难道不能将零除以使我的计算机火上浇油吗？因为，在我的系统（Arch Linux 0.7
i686）上使用我的编译器（g ++ 3.4.3），允许除以零。

C ++说分割后会发生什么零是未定义的。

IEEE表示结果是浮点陷阱或适当签名的无穷大，具体取决于你如何设置。
IEEE。

感谢Andrew。这是一个可怕的消息。 :)

这是否意味着我必须将每个-0乘以-1以获得理智的

表示为零？

" matthias_k" <无**** @ digitalraid.com>在消息中写道

news：ct ************* @ news.t-online.com ...

我目前正在使用修改后的单纯形法实现线性优化问题的求解器，我偶然发现了一些关于数字0处理的奇怪行为。
我是不确定这是编译器还是语言相关的。

第一个问题是，有两个零表示，即
+0和-0。

取决于您获得签名零的方式。价值观，许多不同的事情可能会发生。您应该使用

std :: numeric_limits中定义的常量来计算出发生的情况。

例如，如果问题值来自减法运算，那么你

必须根据机器精度检查它们（例如

std :: numeric_limits< float> :: epsilon（））以确保它们没有全部丢失

意义重大。我想这就是你的情况发生的事情，并且标志位

只是保持不变。

HTH，


戴夫摩尔

Hi,

I am currently implementing a solver for linear optimization problems
using the revised simplex method and I stumbled accross some strange
behavior regarding the treatment of the number 0.
I am not sure whether this is compiler or language related though.

The first problem is, that there are two representations of zero, namely
+0 and -0. Does IEEE for floating points allow this? Maybe I didn''t
activate IEEE floating point numbers?
Anyway, this does have some very annoying consequences, since this
expression:
x / -0 yields -inf (x is positive).

Which brings me to my second question. Shouldn''t division by zero make
my computer go up in flames or so? Because, on my system (Arch Linux 0.7
i686) with my compiler (g++ 3.4.3), dividing by zero is allowed.
In fact, it yields +inf when dividing by +0 and -inf when dividing by
-0, given that the nominator (is that the english term for "Z?hler"?) is
positive of course.

Any comments/ideas?

Regards,
Matthias

解决方案

"matthias_k" <no****@digitalraid.com> wrote in message
news:ct*************@news.t-online.com...

The first problem is, that there are two representations of zero, namely
+0 and -0. Does IEEE for floating points allow this? Maybe I didn''t
activate IEEE floating point numbers?
IEEE floating point requires +0 and -0 as distinct representations.
Anyway, this does have some very annoying consequences, since this
expression:
x / -0 yields -inf (x is positive).
Yes, that is what IEEE floating point requires.
Which brings me to my second question. Shouldn''t division by zero make my
computer go up in flames or so? Because, on my system (Arch Linux 0.7
i686) with my compiler (g++ 3.4.3), dividing by zero is allowed.

C++ says that what happens after division by zero is undefined.

IEEE says that the result is either a floating-point trap or an
appropriately signed infinity, depending on how you have set things up.

The behavior you have described so far is completely normal according to
IEEE.

Andrew Koenig wrote:

"matthias_k" <no****@digitalraid.com> wrote in message
news:ct*************@news.t-online.com...

The first problem is, that there are two representations of zero, namely
+0 and -0. Does IEEE for floating points allow this? Maybe I didn''t
activate IEEE floating point numbers?

IEEE floating point requires +0 and -0 as distinct representations.

Anyway, this does have some very annoying consequences, since this
expression:
x / -0 yields -inf (x is positive).

Yes, that is what IEEE floating point requires.

Which brings me to my second question. Shouldn''t division by zero make my
computer go up in flames or so? Because, on my system (Arch Linux 0.7
i686) with my compiler (g++ 3.4.3), dividing by zero is allowed.

C++ says that what happens after division by zero is undefined.

IEEE says that the result is either a floating-point trap or an
appropriately signed infinity, depending on how you have set things up.

The behavior you have described so far is completely normal according to
IEEE.

Thanks Andrew. That is terrible news. :)
Does that mean I have to multiply each -0 with -1 to get a sane
representation of zero?

"matthias_k" <no****@digitalraid.com> wrote in message
news:ct*************@news.t-online.com...

Hi,

I am currently implementing a solver for linear optimization problems
using the revised simplex method and I stumbled accross some strange
behavior regarding the treatment of the number 0.
I am not sure whether this is compiler or language related though.

The first problem is, that there are two representations of zero, namely
+0 and -0.

Depending on how you are obtaining your "signed zero" values, many different
things could be happening. You should use the constants defined in
std::numeric_limits against your values to figure out what is happening.
For example, if the problem values results from subtraction operations, you
have to check them against the machine accuracy (e.g.
std::numeric_limits<float>::epsilon()) to make sure they haven''t lost all
significance. I guess this is what happened in your case, and the sign bit
is just staying set.
HTH,

Dave Moore

这篇关于关于零的奇怪数值行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！