编译器允许这样做？ [英] Compiler allowed to do this?
问题描述
浮动纳米（长时间下午）
{
返回pm / 1000.0f;
}
无效f（）
{
if（纳米（309311L）==纳米（309311L））
{
//做一些事情
}
}
''if''表达式解析为false，可能是因为一个浮点值存储并重新加载，但是另一个保留在FPU中的扩展精度（我检查了汇编程序）。我知道你在比较花车时必须要小心，但是我希望经过相同操作的相同值能够结束_same_上的
，而且我'' d想知道编译器是否符合标准。
编译器是VS .NET 2003处于调试模式（无优化）并且/ Op开关打开
（提高浮动一致性）。
DW
David W写道：
浮动纳米（长时间下午）
{
返回pm / 1000.0f;
}
void f（）
{
if（纳米（309311L）==纳米（309311L））
{
//做点什么
}
}
''如果''表达式解析为false，可能是因为一个浮点值是
存储和重新加载但另一个浮点数仍然在FPU中以扩展精度保留
（我是xamined汇编程序）。我知道你在比较
浮动时必须要小心，但是我希望相同的值能够进行相同的操作，因为
结束_same_，而我'' d想知道编译器是否符合
标准。
[snip]
我认为编译器属于其权利范围。至少这就是我将如何解释[5/10]的意图：
浮动操作数的值和浮动的结果/>
表达式的表示精度和范围可以比该类型所需的
更高;这些类型没有改变
最好
Kai-Uwe Bux
" Kai- Uwe Bux < jk ******** @ gmx.net写信息
新闻：ee ********** @ murdoch.acc.Virginia.EDU ...
David W写道：
浮动纳米（长时间下午）
{
返回pm / 1000.0f;
}
void f（）
{
if（纳米（309311L）==纳米（309311L））
{
//做点什么
}
}
''if''表达式解析为false，可能是因为一个浮点值
是
存储并重新加载但另一个保留在FPU中的扩展
precision
（我检查了汇编程序）。我知道你在比较
浮动时必须要小心，但是我希望相同的值能够进行相同的操作，因为
结束_same_，而我'' d想知道编译器是否符合
标准。
[snip]
我认为编译器属于其权利范围。至少这就是我将如何解释[5/10]的意图：
浮动操作数的值和浮动的结果/>
表达式的表示精度和范围可以比该类型所需的
更高;这些类型没有改变因此
嗯，这只是要求bug，IMO。直观地说，大多数程序员都希望''if''表达式是真实的，即使是那些知道浮点数问题的人们也会知道
问题。我创建示例的原始代码
在早期的编译器上工作，但是现在它没有，我甚至不能强制使用
编译器来制作这行得通。这是一个大项目，我不知道还有什么地方会有类似的错误，而且不容易找到。
标准或编译器应该比这更好。
具有相同输入的相同表达式应该产生相同的
结果是合理的。在这种情况下，没有必要使用一些
任意最大epsilon来复杂化代码。
DW
David W写道：
>我认为编译器属于其权利范围。至少这就是我如何解释[5/10]的意图：
浮动操作数的值和浮动
表达式的结果可以表示为更大精度和范围比该类型所要求的;这些类型没有改变因此
嗯，这只是要求bug，IMO。直观地说，大多数程序员
会期望''if''表达式是真实的，即使是那些知道
浮点数的圆整问题的人也是如此。我创建
示例的原始代码工作在早期的编译器上，但现在它没有，我甚至不能使用b $ b强制编译器生成这行得通。
您需要的是一个指令，以防止编译器在寄存器中保存值
，其中它们具有另一个精度，就像保持在记忆。我知道
不知道，如果这是一般解决方案（我正在使用gcc），但我声明这样的
变量不应该在寄存器中保存为volatile ，告诉
编译器，该值可以在外部事件中意外改变，而不是由他控制的
。这可以防止某些优化，特别是在寄存器中持有
值。
问候
Stephan
float nanometers(long pm)
{
return pm / 1000.0f;
}
void f()
{
if(nanometers(309311L) == nanometers(309311L))
{
// do something
}
}
The ''if'' expression resolves to false, probably because one float value is stored and reloaded but
the other remains in the FPU in extended precision (I examined the assembler). I know you have to be
careful when comparing floats, but I''d expect the same values undergoing the same operations to end
up the _same_, and I''d like to know if the compiler is conforming to the standard.
The compiler is VS .NET 2003 in debug mode (no optimization) and with the /Op switch turned on
(improve float consistency).
DW
David W wrote:
float nanometers(long pm)
{
return pm / 1000.0f;
}
void f()
{
if(nanometers(309311L) == nanometers(309311L))
{
// do something
}
}
The ''if'' expression resolves to false, probably because one float value is
stored and reloaded but the other remains in the FPU in extended precision
(I examined the assembler). I know you have to be careful when comparing
floats, but I''d expect the same values undergoing the same operations to
end up the _same_, and I''d like to know if the compiler is conforming to
the standard.[snip]
I think the compiler is within its rights. At least that is how I would
interpret the intention of [5/10]:
The values of the floating operands and the results of floating
expressions may be represented in greater precision and range than that
required by the type; the types are not changed thereby
Best
Kai-Uwe Bux
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ee**********@murdoch.acc.Virginia.EDU...David W wrote:
float nanometers(long pm)
{
return pm / 1000.0f;
}
void f()
{
if(nanometers(309311L) == nanometers(309311L))
{
// do something
}
}
The ''if'' expression resolves to false, probably because one float value
is
stored and reloaded but the other remains in the FPU in extended
precision
(I examined the assembler). I know you have to be careful when comparing
floats, but I''d expect the same values undergoing the same operations to
end up the _same_, and I''d like to know if the compiler is conforming to
the standard.[snip]
I think the compiler is within its rights. At least that is how I would
interpret the intention of [5/10]:
The values of the floating operands and the results of floating
expressions may be represented in greater precision and range than that
required by the type; the types are not changed therebyWell, that''s just asking for bugs, IMO. Intuitively, most programmers would
expect the ''if'' expression to be true, even those who are aware of round-off
issues with floats. The original code from which I created the example
worked on an earlier compiler, but now it doesn''t and I can''t even force the
compiler to make it work. It is a large project and I don''t know where else
there will be similar bugs, and it won''t be easy to find out. Either the
standard or the compiler should be better than this. It is reasonable that
identical expressions with identical inputs should produce identical
results. It should not be necessary to complicate the code with some
arbitrary maximum epsilon in a case like this.
DW
David W wrote:
>I think the compiler is within its rights. At least that is how I would
interpret the intention of [5/10]:
The values of the floating operands and the results of floating
expressions may be represented in greater precision and range than that
required by the type; the types are not changed thereby
Well, that''s just asking for bugs, IMO. Intuitively, most programmers
would expect the ''if'' expression to be true, even those who are aware of
round-off issues with floats. The original code from which I created the
example worked on an earlier compiler, but now it doesn''t and I can''t even
force the compiler to make it work.What you need is a directive to prevent that the compiler holds the values
in registers, where they have another precision as if hold in memory. I do
not know, if this is a general solution (I''m using gcc), but I declare such
variables that should not be hold in registers as volatile, which tells the
compiler that the value can change unexpected from external events not
under his control. This prevents certain optimization, especially holding
the value in a register.
Regards
Stephan
这篇关于编译器允许这样做？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
