首页 文章

python 3 floor division并不总是导致int

提问于
浏览 次
1

在python3中使用floor division时（也可能在 future 中使用python2），例如在

>>> 2//2
1

输出是预期的整数 . 但是只要一个操作数是浮点数，就会得到一个浮点数

>>> 2.0//2.0
1.0
>>> 2.0//2
1.0
>>> 2//2.0
1.0

我想这是有意的，但实际上我不明白，为什么它应该是这样的 . 由于总是产生整数的操作，使用先前未确定的数据类型的设计概念是什么？

最好的广泛搜索给了我（来自PEP 238）

Floor Division Floor division的语义将在所有Python数值类型中实现，并具有// b == floor（a / b）的语义
除了结果类型将是在操作之前强制a和b进入的公共类型 . 具体来说，如果a和b属于同一类型，则// b也属于该类型 . 如果输入具有不同类型，则首先使用与所有其他算术运算符相同的规则将它们强制转换为公共类型 . 特别是，如果a和b都是int或long，结果与这些类型的经典除法具有相同的类型和值（包括混合输入类型的情况; int // long和long // int将返回a长） . 对于浮点输入，结果是浮点数 . 例如：3.5 // 2.0 == 1.0
对于复数，//引发异常，因为不允许复数的floor（） . 对于用户定义的类和扩展类型，所有语义都取决于类或类型的实现 .

但这仍然无法解释为什么行为是这样实现的 .

python python-3.x

2 回答

  • 0

    一个可能的优点可能如下：如果操作的输入是 float s，那么通常最有用的输出类型是 float ，因为程序正在进行浮点计算 . 类似地，如果操作的输入是整数（ int s或 long s），那么通常最有用的输出类型是整数 .

    一个相关的令人惊讶的数据点：

    >>> str(int(123e300 // 10.0))
'12300000000000000348405169443457756499452463917650245579212965288916278422109198944984236481408634018703901759913201583616648277756338685989513894763895354330869046350917957229381143786183918719192956157930593465276658607709014541611368487360619735051905095032755082564499801643679232993692080863707136'

    它很自然地会在最后期待很多 0 . 由于 float 类型的精度有限，您得到其他数字 .

    因此，通过返回 float ， // 表示输出可能不准确 .

    回复于
  • 5

    这使得地板划分与其他算术运算一致 . 优点是，您可以使用现有的知识和编码模式，而不是记住 // 是一种特殊情况 . 和所有其他运算符一样，如果要强制输出为 int ，则应明确强制它为此类 .

    回复于

相关问题