2.5 // 2.0
返回Python float
而不是int
Python 3.x 的理由是什么 ?如果它是一个整数值,为什么不把它放在一个类型int
对象中呢?
[编辑]
我正在寻找这样一个事实的理由.以这种方式做出的论点是什么?还没找到它们.
[EDIT2]
这种关系floor
比"地板划分"这个术语更有问题!
floor(3.5 / 5.5) == 0
(INT)
而
3.5 // 5.5 == 0.0
(浮动)
还不能辨别出任何逻辑:(
[EDIT3]
来自PEP238:
在统一模型中,整数1应该与浮点数1.0无法区分(除了它的不精确性),并且两者在所有数字上下文中的行为应该相同.
一切都非常好,但像Numpy这样不重要的图书馆在提供花车作为指数时抱怨,即使它们是不可或缺的.所以'难以区分'还不是现实.花了一些时间来寻找与此相关的错误.我很惊讶地了解了它的真实本质//
.从文档(对我来说)来说并不是那么明显.
由于我对Python 3.x的设计非常信任,我认为我一定错过了//
以这种方式定义的非常明显的理由.但现在我想知道......
该//
运营商覆盖在PEP 238.首先,请注意它不是"整数除法"而是"平面除法",即从未声称结果将是整数.
从楼层划分的语义部分:
分区将在所有Python数字类型中实现,并具有语义
a // b == floor(a/b)除了结果类型将是在操作之前强制a和b进入的公共类型.
然后:
对于浮点输入,结果是浮点数.例如:
3.5//2.0 == 1.0
这个决定背后的理由没有明确说明(或者我找不到).然而,它的实现方式,与其他数学运算(强调我的)是一致的:
具体来说,如果a和b属于同一类型,那么它
a//b
也属于那种类型.如果输入具有不同类型,则首先使用与所有其他算术运算符相同的规则将它们强制转换为公共类型.
此外,如果结果将自动转换为int
,那么对于超出整数精度的非常大的浮点数,这可能会产生奇怪且令人惊讶的结果:
>>> 1e30 // 2. 5e+29 >>> int(1e30 // 2.) 500000000000000009942312419328