java - Python v 3.5.2 和 v 2.7.12 中的结果不同，但 v 2.7.12 是否正确？

Question

让我先说我知道围绕 Python 3，“无限长”被集成到 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=$1
    a=`java    Solution    $i`
    b=`python  Solution.py $i`
    c=`python3 Solution.py $1`

    echo "INPUT: $1"
    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 中整数文字的限制无关。那只是一个转移注意力的问题。您的真正问题是除法运算符 / 在 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 时正确运行，您需要使用 floor 除法运算符 // :

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