在Python底数划分中舍入错误

Question

我知道在浮点算法中会发生舍入错误，但是有人可以解释这一原因：

>>> 8.0 / 0.4  # as expected
20.0
>>> floor(8.0 / 0.4)  # int works too
20
>>> 8.0 // 0.4  # expecting 20.0
19.0

这在x64上的Python 2和Python 3上都发生。

就我所见，这要么是错误，要么是非常愚蠢的规范，//因为我看不出最后一个表达式的求值理由19.0。

为什么a // b不简单定义为floor(a / b)？

编辑 ：8.0 % 0.4也计算为0.3999999999999996。至少这是必然的，因为然后8.0 // 0.4 * 0.4 + 8.0 % 0.4评估为8.0

编辑
：这不是浮点数学运算符被破坏吗？因为我在问为什么这个特定的运算会受到（可能是可以避免的）舍入错误，为什么a // b不定义为/等于floor(a / b)

备注
：我想这不起作用的更深层原因是楼层划分是不连续的，因此条件数无限，这使它成为一个不适定的问题。楼层分割和浮点数根本上是不兼容的，并且绝对不要//在浮点数上使用。只需使用整数或分数即可。

Answer 1

正如您和海尔伍德已经注意到的那样，0.4不能完全表示为浮点数。为什么？它是五分之二（4/10 == 2/5），没有有限的二进制分数表示形式。

尝试这个：

from fractions import Fraction
Fraction('8.0') // Fraction('0.4')
    # or equivalently
    #     Fraction(8, 1) // Fraction(2, 5)
    # or
    #     Fraction('8/1') // Fraction('2/5')
# 20

然而

Fraction('8') // Fraction(0.4)
# 19

在这里，0.4被解释为一个浮动文本（以及因此浮点二进制数）需要（二进制）舍入，并且只有 然后
转化为有理数Fraction(3602879701896397, 9007199254740992)，这几乎是但不完全4/10。然后执行地板划分，而且因为

19 * Fraction(3602879701896397, 9007199254740992) < 8.0

和

20 * Fraction(3602879701896397, 9007199254740992) > 8.0

结果是19，而不是20。

同样的事情可能发生

8.0 // 0.4

即，似乎地板分割是原子确定的（但仅在解释的float文字的近似float值上）。

那为什么

floor(8.0 / 0.4)

给出“正确”的结果？因为在那里，两个舍入错误彼此抵消。 首先
1）进行除法，得到的东西略小于20.0，但不能表示为float。它四舍五入到最接近的浮点数，恰好是20.0。只有到 那时
，该floor操作才被执行，但现在 恰好 作用于该操作20.0，因此不再更改该数字。

1）由于凯尔-斯特兰德指出，该确切的结果确定 则 圆 不是
什么 实际 发生的低2） -电平（CPython中的C代码，甚至CPU指令）。但是，它对于确定预期的3）结果可能是有用的模型。

2）在 最低的
4）级别上，这可能相差不远。一些芯片组通过首先计算更精确的（但仍然不精确，只是具有更多的二进制数字）内部浮点结果，然后舍入为IEEE双精度来确定浮点结果。

3）由Python规范“预期”，不一定是我们的直觉。

4）那么，逻辑门 上方的 最低水平。我们不必考虑使半导体成为可能的量子力学。