Python在float和数字浮点数64

Question

我陷入了一个由浮点精度引起的测试失败中，并试图理解它。在

简而言之：Python3round根据类型是float还是数字浮点数64虽然我认为float==double==float64和Python3和NumPy应该是最接近偶数的。在

这里有一个例子：

npVal = np.float64(435)/100
pyVal = 435/100
print(round(npVal,1))             // 4.4
print(round(pyVal,1))             // 4.3
print(round(np.float64(pyVal),1)) // 4.4
print(round(float(npVal),1))      // 4.3

我知道4.35和4.4可能不能完全用double表示，但是为什么numpyround与Python不同，尽管它们都使用相同的数据类型并指定了相似的函数？我使用显式除法来避免输入舍入错误。在

我不确定，4.35的双精度值是多还是少，所以我不能说这些实现中哪一个是（可能是？）错了。在

还有一个类似的问题：Strange behavior of numpy.round

有人指出，NumPy“舍入到最接近的偶数值”和“python2和python3之间的行为发生了变化；python3在这里的行为与numy相同”。在

所以两者都应该做同样的事情，并四舍五入到最接近的偶数值。所以如果4.35是一个精确的浮点值，那么4.4将是正确的答案，并且需要两者都返回。在

Answer 1

在IEEE-754基本64位二进制浮点中计算435/100得到4.349999999999996447286321199499070644378662109375。在

当四舍五入到小数点后一位的最接近的十进制数时，结果应该是“4.3”。本例中的Python舍入似乎是正确的。在

对于numpy.round，documentation指的是{}。其中的documentation表示“结果也可能令人惊讶，因为……在按10的幂次缩放时引入了错误。”因此，numpy.round可能没有计算出4.34999999999999644728632199499070644378662109375到十进制的正确转换，而是执行该值乘以10的64位二进制浮点乘法，由于浮点舍入，结果正好是43.5，然后numpy.round将其四舍五入到44并将其格式化为“4.4”。在

总之，numpy.round不是一个正确的舍入例程。在