
我知道浮点运算中会发生舍入错误,但有人可以解释一下原因: >>> 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

1
评论 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
请先 登录 后发表评论~