我知道浮点运算中会发生舍入错误，但有人可以解释一下原因： >>> 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 和 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) 备注：我想这不起作用的更深层原因是楼层划分是不连续的，因此具有无限的条件数，使其成为一个不适定问题。地板除法和浮点数根本不兼容，你永远不应该//在浮点数上使用。只需使用整数或分数。
0
2
评论 1
卓越助教
正如您和 khelwood 已经注意到的那样，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
即，似乎地板除法是原子确定的（但在解释的浮点文字的唯一近似浮点值上）。
那为什么
floor(8.0 / 0.4)
给出“正确”的结果？因为在那里，两个舍入误差相互抵消。首先1)执行除法，产生的结果略小于 20.0，但不能表示为浮点数。它被四舍五入到最接近的浮点数，恰好是20.0. 只有这样，floor操作才被执行，但现在完全 作用于20.0，因此不再更改数字。
1）由于凯尔-斯特兰德指出，该确切的结果确定则
2022-01-13 16:04:35
0
- 没有更多了 -
作者
Python互动课话题
0/300
请先 登录 后发表评论~