好的，我知道关于pow函数并将其结果转换为int有很多问题，但是我找不到这个特定问题的答案。

OK，这是C代码：

#include

#include

#include

int main()

{

int i = 5;

int j = 2;

double d1 = pow(i,j);

double d2 = pow(5,2);

int i1 = (int)d1;

int i2 = (int)d2;

int i3 = (int)pow(i,j);

int i4 = (int)pow(5,2);

printf("%d %d %d %d",i1,i2,i3,i4);

return 0;

}

这是输出：" 25 25 24 25"。 注意，只有在第三种情况下，pow的参数不是文字，我们才得到错误的结果，可能是由于舍入错误引起的。 没有显式强制转换，也会发生相同的事情。 有人可以解释这四种情况吗？

我在Windows 7和随附的MinGW gcc编译器中使用CodeBlocks。

您要确切解释什么？ 24和25都是正确答案。 该实现会执行最有效的操作。

我的输出是25 25 25 25。 那真是怪了。

@ user2448027尝试禁用所有优化。

在Ubuntu系统中，我也得到" 25 25 25 25"，这仅在Windows中发生。 而且只有第三种情况，那才是最有趣的。

@Marko如果禁用Ubuntu中的所有优化会怎样？

@ user2448027对不起，我的回答很晚。 所有优化均已禁用。 但是，使用-O3优化时，我也会得到正确的结果。

pow操作的结果为25.0000，加上或减去一些舍入误差。如果舍入误差为正或为零，则转换为整数将产生25。如果舍入误差为负，则结果为24。两个答案都是正确的。

内部最有可能发生的情况是，一种情况是直接使用精度更高的80位FPU值，另一种情况是将结果从FPU写入内存(为64位double值)，并且然后读回(将其转换为稍有不同的80位值)。这可以在最终结果中产生微观差异，这就是将25.0000000001更改为24.999999997所需的全部

另一种可能性是，编译器会识别传递给pow的常量，然后自己进行计算，将结果替换为对pow的调用。您的编译器可以使用内部的任意精度数学库，也可以仅使用一个不同的数学库。

舍入永远不会将大于25的值更改为小于25的值。即使不知道浮点算术的规则或机制，术语"舍入"也是一个大提示：24.999999997的舍入不大于25.0000000001。浮点算术不是随机数生成器。

@EricPostpischil我同意。那不是我在说什么。林说的是，舍入可以将原本为25的值舍入为24.9999997或25.000001。从不能保证重复执行完全相同的操作的意义上讲，浮点算术可以是随机数生成器。

重复执行完全相同的操作会产生完全相同的结果。在这种情况下，由于C实现无法明确地将源代码绑定到浮点操作，因此不重复操作。即使这样，每次操作每次执行都会产生相同的结果。只是看起来相似的源代码(不完全相同)会产生不同的结果。这是C实现的缺陷，而不是浮点算法的缺陷。

@EricPostpischil您在争论语义，并给一个非常简单的问题增加混乱和不必要的复杂性。严格来说，您永远无法执行两次"完全相同的操作"。问题是您无法知道哪些更改会导致不同的浮点结果。 (如果更改编译器版本，是否执行完全相同的操作？如果升级CPU，是否进行？)此处没有"缺陷"。这就是应该的样子。如果存在缺陷，则可以期待。

这不是语义，因为它告诉您在哪里寻找答案。如果您使用C标准来控制浮点，则会遇到麻烦。如果您遵循IEEE 754标准，则会发现完全指定的操作。关于您的问题：如果更改编译器版本，则操作不一定相同。如果更改CPU型号，则基本操作是相同的(诸如reciprocal-square-root-estimate之类的深奥操作可能会有所不同)。您提倡无知，断言这些事情是未知的。但是它们是已知的并且可以控制的。

@EricPostpischil：这是一个C问题。它与IEEE 754无关。如果您认为我的陈述不正确或具有误导性，则必须同意不同意。如果您认为它们不完整-当然可以。从C或C ++程序员的角度来看，即使从语言的角度来看，即使浮点运算看起来是相同的，也试图理解为什么浮点运算会给它们带来不一致的结果，答案很简单-规范允许实现提供任何"合理的""，并且除非合理，否则不需要保持一致。

这是由两个问题的组合引起的：

您使用的pow的实现质量不是很高。在许多情况下，浮点算术都必须是近似值，但是良好的实现应注意确保诸如pow(5, 2)之类的简单情况返回准确的结果。您正在使用的pow返回的结果小于25且数量大于0但小于或等于2–49。例如，它可能返回25–2-50。

您使用的C实现有时使用64位浮点格式，有时使用80位浮点格式。只要数字以80位格式保留，它就保留pow返回的完整值。如果将此值转换为整数，则会产生24，因为该值小于25，并且转换为整数截断；它不圆。将数字转换为64位格式时，将对其进行舍入。在浮点格式之间进行舍入，因此结果舍入为最接近的可表示值25。此后，转换为整数将产生25。

从某种意义上说，只要"方便"，编译器就可以切换格式。例如，数量有限的80位格式的寄存器。当它们已满时，编译器可能会将某些值转换为64位格式，并将其存储在内存中。编译器还可以在编译时而不是在运行时重新排列表达式或执行表达式的一部分，这些表达式可能会影响所执行的算法和所使用的格式。

当C实现混用浮点格式时，这很麻烦，因为用户通常无法预测或控制何时进行格式之间的转换。这会导致结果难以再现，并且会干扰软件的数值属性的推导或控制。可以将C实现设计为始终使用单一格式，并避免其中的某些问题，但您的C实现显然不是这样设计的。

除了你的最后一段，我都同意。当实现不混合浮点格式时，实际上更糟。然后，您的代码似乎可以正常工作，并且漏洞会被忽略。正是由于他的实现，他才知道他不能在一个实际上不能依赖于可预测的领域中依靠可预测的实现。当您做错了什么时，由于失败而导致实施失败的时间越早，越好。

@DavidSchwartz：这是有害的立场，主张程序员接受草率的编译器。当编译器的行为使设计好的软件变得困难时，应将其视为编译器中的错误。 (符合C标准不是编译器的终点。它们可以并且应该超越此标准，并且应该在其浮点规范中进行改进。)

对于不需要拧紧的人，拧紧标准将导致较差的性能。 这可能是一个不错的折衷，但我并不相信。 只要标准允许这种行为，要么必须将代码限制为仅在指定为以超出标准要求的特定方式运行的编译器上运行，否则代码将被破坏。 我认为主张代码应围绕某些特定编译器可能提供的保证而构建是错误的，尤其是因为您是根据表现行为(而不是保证)来表达自己的评论。

要在此处添加其他答案：使用浮点值时通常要非常小心。

我强烈建议您阅读本文(即使阅读时间很长)：

http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdf

跳至第3节以获取实际示例，但请不要忽略前面的章节！

我相当确定这可以通过"中间舍入"和pow不是简单地循环乘以i而是围绕j倍，而是使用exp(log(i)*j)作为浮点计算的事实来解释。中间舍入可以很好地将24.999999999996转换为25.000000000-即使值的任意存储和重装也可能导致这种行为上的差异，因此，取决于代码的生成方式，它可能会与实际结果有所不同。

当然，在某些情况下，编译器甚至可以"知道" pow的实际作用，并用恒定的结果替换计算。