java-在Python v 3.5.2和v 2.7.12中结果不同,但是v 2.7.12是正确的吗？

首先,我要说一下我的问题,我知道在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"

这是一些示例运行. RESULT列很重要.

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？

我如何纠正任何错误才能获得正确的输出？

解决方法:

该问题实际上与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
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.

因此,如果您希望当输入为123456789987654321时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

标签：long-integer,biginteger,python,java
来源： https://codeday.me/bug/20191109/2012857.html