CODEWITHSUNDEEP
pythonperlawkroundinglong-integer
terdon
terdon

Reputation: 3380

Why do 4 different languages give 4 different results here?

Consider this (all commands run on an 64bit Arch Linux system):

So, Perl, gawk and R agree, as do bc and Pyhon 2. Nevertheless, between the 6 tools tested, I got 4 different results. I understand that this has something to do with how very long integers are being rounded, but why do the different tools differ quite so much? I had expected that this would depend on the processor's ability to deal with large numbers, but it seems to depend on internal features (or bugs) of the language.

Could someone explain what is going on behind the scenes here? What are the limitations in each language and why do they behave quite so differently?

Upvotes: 5

Views: 264

Answers (3)

echo
echo

Reputation: 3134

in perl6

➜  ~  perl6 -e 'say(10190150730169267102 div 1000 mod 10)'
7
➜  ~  perl6 -e 'say(10190150730169267102/1000%10)'
7.102

so, If you are not sure which language is correct, try to ask Perl6. :)

Upvotes: 1

Mark Dickinson
Mark Dickinson

Reputation: 30591

You're seeing different results for two reasons:

  1. The division step is doing two different things: in some of the languages you tried, it represents integer division, which discards the fractional part of the result and just keeps the integer part. In others it represents actual mathematical division (which following Python's terminology I'll call "true division" below), returning a floating-point result close to the true quotient.

  2. In some languages (those with support for arbitrary precision), the large numerator value 10190150730169267102 is being represented exactly; in others, it's replaced by the nearest representable floating-point value.

The different combinations of the possibilities in 1. and 2. above give you the different results.

In detail: in Perl, awk, and R, we're working with floating-point values and true division. The value 10190150730169267102 is too large to store in a machine integer, so it's stored in the usual IEEE 754 binary64 floating-point format. That format can't represent that particular value exactly, so what gets stored is the closest value that is representable in that format, which is 10190150730169266176.0. Now we divide that approximation by 1000, again giving a floating-point result. The exact quotient, 10190150730169266.176, is again not exactly representable in the binary64 format, and we get the closest representable float, which happens to be 10190150730169266.0. Taking a remainder modulo 10 gives 6.

In bc and Python 2, we're working with arbitrary-precision integers and integer division. Both those languages can represent the numerator exactly. The division result is then 10190150730169267 (we're doing integer division, not true division, so the fractional part is discarded), and the remainder modulo 10 is 7. (This is oversimplifying a bit: the format that bc is using internally is somewhat closer to Python's Decimal type than to an arbitrary-precision integer type, but in this case the effect is the same.)

In Python 3, we're working with arbitrary-precision integers and true division. The numerator is represented exactly, but the result of the division is the nearest floating-point value to the true quotient. In this case the exact quotient is 10190150730169267.102, and the closest representable floating-point value is 10190150730169268.0. Taking the remainder of that value modulo 10 gives 8.

Summary:

  • Perl, awk, R: floating-point approximations, true division
  • bc, Python 2: arbitrary-precision integers, integer division
  • Python 3: arbitrary-precision integers, true division

Upvotes: 9

Julien
Julien

Reputation: 1910

I can answer only for the difference between python 2 and python 3. "/" is integer division in python 2 while it is real division in python 3 (that's where the .0 in python 3 comes from. The output is floating point.

To summarize:

  • Python 2

    10190150730169267102/1000%10

    equals 

    10190150730169267%10

    equals

    7

  • Python 3

    10190150730169267102/1000%10

    equals 

    10190150730169267,102%10

    equals 

    7.102

but because of internal representation it's (wrongly) computed to 8.0

You may note that the correct answer may be 7 or 7.102 depending if we consider the division to be floating point or integer. So only Python(2) and bc have correct answers. And python 3 would have correct answer with integer division (10190150730169267102//1000%10).

Python supports arbitrarily large integers natively!

Upvotes: 3

Related Questions