Python v 3.5.2 和 v 2.7.12 的结果不同，但是 v 2.7.12 是正确的吗？

Question

让我先说我知道在 Python 3 左右，"limitless long" 被集成到 int 中，因此 Python 中的 int 可以和你的 RAM 一样大.

我正在比较 Java 和 Python。下面是一个Python和Java的程序。他们做同样的事情。

Python:

def answer(n):
    count = 0
    t = int(n)
    while (t!=1):
        t = t+1 if (t%2==1) else t/2
        count += 1
    return count

Java:

static int answer(String n){
    int count = 0;
    BigInteger t = new BigInteger(n)

    while(!t.equals(BigInteger.ONE)){
        t = ((t.remainder(new BigInteger("2"))).equals(BigInteger.ONE))
            ?t.add(new BigInteger("1"))
            :t.divide(new BigInteger("2"));
        count++;
    }
    return count;
}

然后我写了一个简单的 bash 脚本到运行 java 和 python（作为版本 2.7.12 和 3.5.2）并比较它们的输出.

#!/bin/bash
    i=
    a=`java    Solution    $i`
    b=`python  Solution.py $i`
    c=`python3 Solution.py `

    echo "INPUT: "
    echo ""
    echo "LANGUAGE: VERSION:  RESULT:"
    echo "--------  --------- ------"
    echo "Java      1.8.0_151   $a"
    echo "Python    2.7.12      $b"
    echo "Python3   3.5.2       $c"

这里有一些示例运行。结果列很重要。

INPUT: 123

LANGUAGE: VERSION:  RESULT:
--------  --------- ------
Java      1.8.0_151   9
Python    2.7.12      9
Python3   3.5.2       9


INPUT: 123456789

LANGUAGE: VERSION:  RESULT:
--------  --------- ------
Java      1.8.0_151   39
Python    2.7.12      39
Python3   3.5.2       39


INPUT: 12345678998765

LANGUAGE: VERSION:  RESULT:
--------  --------- ------
Java      1.8.0_151   61
Python    2.7.12      61
Python3   3.5.2       61


INPUT: 123456789987654321

LANGUAGE: VERSION:  RESULT:
--------  --------- ------
Java      1.8.0_151   84
Python    2.7.12      84
Python3   3.5.2       82

所以它们几乎都产生相同的结果，直到输入变得足够大，然后你可以看到最后一个结果是不同的。几乎每个大于此的数字都会产生不同的结果。

Python3 的 int 和 Java 的 BigInteger 不应该得到相同的结果吗？

Python v.2 不应该是得到不同结果的那个吗？

哪一个实际上是错误的，为什么？ Java 和 Python3 还是只是 Python v.2.7.12？

如何更正错误以获得正确的输出？

Answer 1

这个问题实际上与 Python 2 中整数文字的限制无关。那只是一个 red-herring。您的 真正的 问题是除法运算符 / 在 Python 2 中的行为与在 Python 3.

中的行为不同

PEP 238 documents this change:

The current division (/) operator has an ambiguous meaning for numerical arguments: it returns the floor of the mathematical result of division if the arguments are ints or longs, but it returns a reasonable approximation of the division result if the arguments are floats or complex. This makes expressions expecting float or complex results error-prone when integers are not expected but possible as inputs.

We propose to fix this by introducing different operators for different operations: x/y to return a reasonable approximation of the mathematical result of the division ("true division"), x//y to return the floor ("floor division"). We call the current, mixed meaning of x/y "classic division".

Because of severe backwards compatibility issues, not to mention a major flamewar on c.l.py, we propose the following transitional measures (starting with Python 2.2):

Classic division will remain the default in the Python 2.x series; true division will be standard in Python 3.0.

The // operator will be available to request floor division
unambiguously.

The future division statement, spelled from __future__ import<br> division, will change the / operator to mean true division throughout the module.

A command line option will enable run-time warnings for classic
division applied to int or long arguments; another command line
option will make true division the default.

The standard library will use the future division statement and the
// operator when appropriate, so as to completely avoid classic
division.

因此，如果您希望 Python 代码在输入 123456789987654321 时正确运行，您需要使用底除运算符 //:

def answer(n):
    count = 0
    t = int(n)
    while t != 1:
        t = t + 1 if (t % 2==1) else t // 2
        count += 1
    return count

Python v 3.5.2 和 v 2.7.12 的结果不同，但是 v 2.7.12 是正确的吗？

Different results in Python v 3.5.2 and v 2.7.12, but the v 2.7.12 is correct?

python

java

biginteger

long-integer