为什么在不同情况下在不同情况下调用POW（）有时会产生不同的结果？ 我想知道什么可以解释我今天观察到的浮点差异。是一个错误还是绊倒一些不确定的行为？以下是代码。我的希望是理解这种行为...

Question

8
12020.670425990641888347454369
8
x = 402e11a56f0d331e
y = 400bba9d55e142e0
r = 40c77a55d084d419
12020.670425990641888347454369

在同一VM中使用GCC：

8
12020.670425990643707336857915
8
x = 402e11a56f0d331e
y = 400bba9d55e142e0
r = 40c77a55d084d419
12020.670425990641888347454369

在同一台计算机上使用MacOS上的叮当声：

8
12020.670425990643707336857915
8
x = 402e11a56f0d331e
y = 400bba9d55e142e0
r = 40c77a55d084d41a
12020.670425990643707336857915

abibinga

.

Answer 1

pow

和gcc都在编译时对其进行计算，并且它们对其进行了不同的计算。区别在于至少有显着的位置。

您的操作数根本不可能完全表示为IEEE双重。一个无限精确的计算器表明，GCC使用确切的操作数，并以比

clang

报价更高的精度计算答案，然后将结果转换为

double

与之那样。没有正确或错误的行为，都按照标准是正确的。
    

我希望是了解行为，以便我可以在编译器，处理器和平台之间保持一致。

说，X

Y

的一致性义务超过±0.5000 ...

ulp

.

。

Answer 2

double

操作数值？

^{没有15.034465284692086 nor 3.466120406090667完全代表为}double，而是附近的值用于pow(x,y)

---

double

什么是x, y

？

MASTHEMATION，15.0344652846920 858735 ...

3.46612040609066696106 ...

是：

//                          15.0344652846920 86
x = 0x1.e11a56f0d331ep+3    15.0344652846920 85873530231765471398830413818359375
y = 0x1.bba9d55e1420ep+1    3.46612040609066 69610631070099771022796630859375
//                          3.46612040609066 7

是：是：

pow(x,y)

两个不同的答案是1.0 ULP。 数学答案大约为2个可能的结果之间的50.05％点。 随着较宽的

0x1.77a55d084d419 802...p+13 12020.67042599064 2798519464085... extended math ^{，如果结果结果，结果仍然超过50％。 在这种情况下，两者中的较大（clang Mac）是更好的答案。 即使使用原始代码常数，Clang Mac也更好。}

为什么在不同情况下在不同情况下调用POW（）有时会产生不同的结果？ 审视

table-Maker的困境

诸如

pow(x,y)

（试图近似数学X

Y

）之类的转换计算遇到了一个困难的问题：内部计算必须多少精度才能导致

best

？  对于X

Y
而言，通常的方法是用额外的（但不是太多）执行计算，因为这会减慢性能，但只有每一个额外的数字略微增加了

best的出现率。

仅仅是因为使用更精确，更好的算法或选择的阀门，某些

0x1.77a55d084d419       p+13  12020.67042599064 1888347454369... Clang Linux
0x1.77a55d084d419       p+13  12020.67042599064 1888347454369... GCC Linux
0x1.77a55d084d41a       p+13  12020.67042599064 3707336857915... Clang MAC

0x1.77a55d084d419 80c   p+13  12020.67042599064 2803171226660... powl(x, y) double args
0x1.77a55d084d41a 640...p+13  12020.67042599064 4417576265463... extended math with code's constants

计算在将近一半的情况下的表现要比另一个计算更好（另一种方法可能更常见地提供更好的答案 - 这是只有1个。）

consistency
库库应该期待什么。H库是最佳答案的1.0 ULP之内的结果。 在这里，两个答案都在最佳答案的0.5005 ULP之内。 期望在0.5000以内的答案... ULP对于XY而言是一个越来越大的问题，不应被期望。