Unerwartete Ergebnisse bei der Arbeit mit sehr großen Ganzzahlen in interpretierten Sprachen

Ich versuche , die Summe zu bekommen 1 + 2 + ... + 1000000000, aber ich bin immer lustig Ergebnisse in PHP und Node.js .

PHP

$sum = 0;
for($i = 0; $i <= 1000000000 ; $i++) {
    $sum += $i;
}
printf("%s", number_format($sum, 0, "", ""));   // 500000000067108992

Node.js

var sum = 0;
for (i = 0; i <= 1000000000; i++) {
    sum += i ;
}
console.log(sum); // 500000000067109000

Die richtige Antwort kann mit berechnet werden

1 + 2 + ... + n = n(n+1)/2

Richtige Antwort = 500000000500000000 , also habe ich beschlossen, eine andere Sprache auszuprobieren.

GEHEN

var sum , i int64
for i = 0 ; i <= 1000000000; i++ {
    sum += i
}
fmt.Println(sum) // 500000000500000000

Aber es funktioniert gut! Was ist also falsch an meinem PHP- und Node.js-Code?

Vielleicht ist dies ein Problem interpretierter Sprachen, und deshalb funktioniert es in einer kompilierten Sprache wie Go? Wenn ja, hätten andere interpretierte Sprachen wie Python und Perl das gleiche Problem?

Python funktioniert:

>>> sum(x for x in xrange(1000000000 + 1))
500000000500000000

Oder:

>>> sum(xrange(1000000000+1))
500000000500000000

Pythons intAuto wird zu einem Python longhochgestuft, der beliebige Genauigkeit unterstützt. Auf 32- oder 64-Bit-Plattformen wird die richtige Antwort ausgegeben.

Dies kann gesehen werden, indem 2 auf eine Leistung angehoben wird, die weit größer als die Bitbreite der Plattform ist:

>>> 2**99
633825300114114700748351602688L

Sie können (mit Python) demonstrieren, dass die fehlerhaften Werte, die Sie in PHP erhalten, darauf zurückzuführen sind, dass PHP zu einem Float hochgestuft wird, wenn die Werte größer als 2 ** 32-1 sind:

>>> int(sum(float(x) for x in xrange(1000000000+1)))
500000000067108992

Ihr Go-Code verwendet eine Ganzzahlarithmetik mit genügend Bits, um eine genaue Antwort zu geben. Nie PHP oder Node.js berührt, aber aufgrund der Ergebnisse vermute ich, dass die Berechnung mit Gleitkommazahlen durchgeführt wird und daher erwartet werden sollte, dass sie für Zahlen dieser Größenordnung nicht genau sind.

Der Grund ist, dass der Wert Ihrer Ganzzahlvariablen sumden Maximalwert überschreitet. Und das, was sumSie erhalten, ist das Ergebnis einer Gleitkomma-Arithmetik, bei der abgerundet wird. Da in anderen Antworten die genauen Grenzen nicht erwähnt wurden, habe ich beschlossen, sie zu veröffentlichen.

Der maximale ganzzahlige Wert für PHP für:

• Die 32-Bit-Version ist 2147483647
• Die 64-Bit-Version lautet 9223372036854775807

Dies bedeutet, dass Sie entweder eine 32-Bit-CPU oder ein 32-Bit-Betriebssystem oder eine 32-Bit-kompilierte Version von PHP verwenden. Es kann mit gefunden werden PHP_INT_MAX. Das sumwürde korrekt berechnet, wenn Sie es auf einem 64-Bit-Computer tun.

Der maximale ganzzahlige Wert in JavaScript beträgt 9007199254740992 . Der größte exakte Integralwert, mit dem Sie arbeiten können, ist 2 ⁵³ (aus dieser Frage entnommen ). Das sumüberschreitet diese Grenze.

Wenn der ganzzahlige Wert diese Grenzwerte nicht überschreitet, sind Sie gut. Andernfalls müssen Sie nach Ganzzahlbibliotheken mit beliebiger Genauigkeit suchen.

Hier ist der Vollständigkeit halber die Antwort in C:

#include <stdio.h>

int main(void)
{
    unsigned long long sum = 0, i;

    for (i = 0; i <= 1000000000; i++)    //one billion
        sum += i;

    printf("%llu\n", sum);  //500000000500000000

    return 0;
}

Der Schlüssel in diesem Fall ist die Verwendung des long long Datentyps von C99 . Es bietet den größten primitiven Speicher, den C verwalten kann, und läuft sehr, sehr schnell. Der long longTyp funktioniert auch auf den meisten 32- oder 64-Bit-Computern.

Es gibt eine Einschränkung: Von Microsoft bereitgestellte Compiler unterstützen den 14 Jahre alten C99-Standard ausdrücklich nicht. Daher ist es ein Crapshot, diesen in Visual Studio auszuführen.

Ich vermute, wenn die Summe die Kapazität eines nativen Systems überschreitet int(2 ³¹ -1 = 2.147.483.647), wechseln Node.js und PHP zu einer Gleitkommadarstellung und es treten Rundungsfehler auf. Eine Sprache wie Go wird wahrscheinlich versuchen, so lange wie möglich bei einer Ganzzahlform (z. B. 64-Bit-Ganzzahlen) zu bleiben (wenn dies tatsächlich nicht damit begonnen hat). Da die Antwort in eine 64-Bit-Ganzzahl passt, ist die Berechnung genau.

Perl-Skript geben uns das erwartete Ergebnis:

use warnings;
use strict;

my $sum = 0;
for(my $i = 0; $i <= 1_000_000_000; $i++) {
    $sum += $i;
}
print $sum, "\n";  #<-- prints: 500000000500000000

Die Antwort darauf ist "überraschend" einfach:

Erstens reicht - wie die meisten von Ihnen vielleicht wissen - eine 32-Bit-Ganzzahl von –2.147.483.648 bis 2.147.483.647 . Was passiert also, wenn PHP ein Ergebnis erzielt, das GRÖSSER ist?

Normalerweise würde man einen sofortigen "Überlauf" erwarten, wodurch 2.147.483.647 + 1 zu -2.147.483.648 werden . Dies ist jedoch NICHT der Fall. Wenn PHP auf eine größere Zahl stößt, wird FLOAT anstelle von INT zurückgegeben.

Wenn PHP auf eine Zahl stößt, die über die Grenzen des Integer-Typs hinausgeht, wird sie stattdessen als Float interpretiert. Außerdem gibt eine Operation, die zu einer Zahl führt, die über die Grenzen des Integer-Typs hinausgeht, stattdessen einen Float zurück.

http://php.net/manual/en/language.types.integer.php

Das heißt, und zu wissen, dass die Implementierung von PHP FLOAT dem IEEE 754-Format mit doppelter Genauigkeit folgt, bedeutet, dass PHP in der Lage ist, Zahlen bis zu 52 Bit zu verarbeiten, ohne an Genauigkeit zu verlieren. (Auf einem 32-Bit-System)

An dem Punkt, an dem Ihre Summe 9.007.199.254.740.992 erreicht (das sind 2 ^ 53 ), ist der von PHP Maths zurückgegebene Float-Wert nicht mehr genau genug.

E:\PHP>php -r "$x=bindec(\"100000000000000000000000000000000000000000000000000000\"); echo number_format($x,0);"

9.007.199.254.740.992

E:\PHP>php -r "$x=bindec(\"100000000000000000000000000000000000000000000000000001\"); echo number_format($x,0);"

9.007.199.254.740.992

E:\PHP>php -r "$x=bindec(\"100000000000000000000000000000000000000000000000000010\"); echo number_format($x,0);"

9.007.199.254.740.994

Dieses Beispiel zeigt den Punkt, an dem PHP an Genauigkeit verliert. Zuerst wird das letzte signifikante Bit gelöscht, wodurch die ersten beiden Ausdrücke zu einer gleichen Anzahl führen - was sie nicht sind.

Ab JETZT wird die gesamte Mathematik schief gehen, wenn mit Standarddatentypen gearbeitet wird.

• Ist es das gleiche Problem für andere interpretierte Sprachen wie Python oder Perl?

Das glaube ich nicht. Ich denke, dies ist ein Problem von Sprachen, die keine Typensicherheit haben. Während ein Integer-Überlauf wie oben erwähnt in jeder Sprache auftritt, die feste Datentypen verwendet, versuchen die Sprachen ohne Typensicherheit möglicherweise, dies mit anderen Datentypen abzufangen. Sobald sie jedoch ihre "natürliche" (vom System vorgegebene) Grenze erreicht haben, können sie alles zurückgeben, aber das richtige Ergebnis.

Jede Sprache kann jedoch unterschiedliche Threadings für ein solches Szenario haben.

Die anderen Antworten erklärten bereits, was hier passiert (Gleitkommapräzision wie gewohnt).

Eine Lösung besteht darin, einen ganzzahligen Typ zu verwenden, der groß genug ist, oder zu hoffen, dass die Sprache bei Bedarf einen auswählt.

Die andere Lösung besteht darin, einen Summationsalgorithmus zu verwenden, der das Präzisionsproblem kennt und es umgeht. Unten finden Sie dieselbe Summierung, zuerst mit 64-Bit-Ganzzahl, dann mit 64-Bit-Gleitkomma und dann wieder mit Gleitkomma, jedoch mit dem Kahan-Summierungsalgorithmus .

Geschrieben in C #, aber das Gleiche gilt auch für andere Sprachen.

long sum1 = 0;
for (int i = 0; i <= 1000000000; i++)
{
    sum1 += i ;
}
Console.WriteLine(sum1.ToString("N0"));
// 500.000.000.500.000.000

double sum2 = 0;
for (int i = 0; i <= 1000000000; i++)
{
    sum2 += i ;
}
Console.WriteLine(sum2.ToString("N0"));
// 500.000.000.067.109.000

double sum3 = 0;
double error = 0;
for (int i = 0; i <= 1000000000; i++)
{
    double corrected = i - error;
    double temp = sum3 + corrected;
    error = (temp - sum3) - corrected;
    sum3 = temp;
}
Console.WriteLine(sum3.ToString("N0"));
//500.000.000.500.000.000

Die Kahan-Summe ergibt ein schönes Ergebnis. Die Berechnung dauert natürlich viel länger. Ob Sie es verwenden möchten, hängt a) von Ihren Leistungs- und Präzisionsanforderungen ab und b) davon, wie Ihre Sprache mit Ganzzahl- und Gleitkomma-Datentypen umgeht.

Wenn Sie 32-Bit-PHP haben, können Sie es mit bc berechnen :

<?php

$value = 1000000000;
echo bcdiv( bcmul( $value, $value + 1 ), 2 );
//500000000500000000

In Javascript müssen Sie eine beliebige Zahlenbibliothek verwenden , zum Beispiel BigInteger :

var value = new BigInteger(1000000000);
console.log( value.multiply(value.add(1)).divide(2).toString());
//500000000500000000

Selbst bei Sprachen wie Go und Java müssen Sie möglicherweise eine beliebige Nummernbibliothek verwenden. Ihre Nummer war zufällig klein genug für 64-Bit, aber zu hoch für 32-Bit.

In Ruby:

sum = 0
1.upto(1000000000).each{|i|
  sum += i
}
puts sum

Druckt 500000000500000000, dauert aber auf meinem 2,6 GHz Intel i7 gut 4 Minuten.

Magnuss und Jaunty haben eine viel mehr Ruby-Lösung:

1.upto(1000000000).inject(:+)

So führen Sie einen Benchmark durch:

$ time ruby -e "puts 1.upto(1000000000).inject(:+)"
ruby -e "1.upto(1000000000).inject(:+)"  128.75s user 0.07s system 99% cpu 2:08.84 total

Ich benutze Node-Bigint für große Ganzzahlen:
https://github.com/substack/node-bigint

var bigint = require('bigint');
var sum = bigint(0);
for(var i = 0; i <= 1000000000; i++) { 
  sum = sum.add(i); 
}
console.log(sum);

Es ist nicht so schnell wie etwas, das native 64-Bit-Inhalte für diesen genauen Test verwenden kann. Wenn Sie jedoch größere Zahlen als 64-Bit verwenden, wird libgmp unter der Haube verwendet, eine der schnelleren Bibliotheken mit beliebiger Genauigkeit.

hat ewig in Rubin gedauert, gibt aber die richtige Antwort:

(1..1000000000).reduce(:+)
 => 500000000500000000 

Um das richtige Ergebnis in PHP zu erhalten, müssten Sie vermutlich die BC-Mathematikoperatoren verwenden: http://php.net/manual/en/ref.bc.php

Hier ist die richtige Antwort in Scala. Sie müssen Longs verwenden, sonst überlaufen Sie die Nummer:

println((1L to 1000000000L).reduce(_ + _)) // prints 500000000500000000

Es gibt tatsächlich einen coolen Trick zu diesem Problem.

Angenommen, es war stattdessen 1-100.

1 + 2 + 3 + 4 + ... + 50 +

100 + 99 + 98 + 97 + ... + 51

= (101 + 101 + 101 + 101 + ... + 101) = 101 * 50

Formel:

Für N = 100: Ausgang = N / 2 * (N + 1)

Für N = 1e9: Ausgabe = N / 2 * (N + 1)

Dies ist viel schneller als das Durchlaufen all dieser Daten. Ihr Prozessor wird es Ihnen danken. Und hier ist eine interessante Geschichte zu diesem Problem:

http://www.jimloy.com/algebra/gauss.htm

Dies ergibt das richtige Ergebnis in PHP, indem die Ganzzahlumwandlung erzwungen wird.

$sum = (int) $sum + $i;

Common Lisp ist eine der am schnellsten interpretierten * Sprachen und verarbeitet beliebig große Ganzzahlen standardmäßig korrekt. Dies dauert bei SBCL ca. 3 Sekunden :

* (time (let ((sum 0)) (loop :for x :from 1 :to 1000000000 :do (incf sum x)) sum))

Evaluation took:
  3.068 seconds of real time
  3.064000 seconds of total run time (3.044000 user, 0.020000 system)
  99.87% CPU
  8,572,036,182 processor cycles
  0 bytes consed

500000000500000000

• Mit interpretiert meine ich, ich habe diesen Code von der REPL ausgeführt. SBCL hat möglicherweise intern JITing durchgeführt, damit er schnell ausgeführt wird, aber die dynamische Erfahrung, Code sofort auszuführen, ist dieselbe.

Ich habe nicht genug Ruf, um die Common Lisp-Antwort von @ postfuturist zu kommentieren, aber sie kann so optimiert werden, dass sie mit SBCL 1.1.8 auf meinem Computer in ~ 500 ms abgeschlossen ist:

CL-USER> (compile nil '(lambda () 
                        (declare (optimize (speed 3) (space 0) (safety 0) (debug 0) (compilation-speed 0))) 
                        (let ((sum 0))
                          (declare (type fixnum sum))
                          (loop for i from 1 to 1000000000 do (incf sum i))
                          sum)))
#<FUNCTION (LAMBDA ()) {1004B93CCB}>
NIL
NIL
CL-USER> (time (funcall *))
Evaluation took:
  0.531 seconds of real time
  0.531250 seconds of total run time (0.531250 user, 0.000000 system)
  100.00% CPU
  1,912,655,483 processor cycles
  0 bytes consed

500000000500000000

Racket v 5.3.4 (MBP; Zeit in ms):

> (time (for/sum ([x (in-range 1000000001)]) x))
cpu time: 2943 real time: 2954 gc time: 0
500000000500000000

Funktioniert gut in Rebol:

>> sum: 0
== 0

>> repeat i 1000000000 [sum: sum + i]
== 500000000500000000

>> type? sum
== integer!

Hierbei wurde Rebol 3 verwendet, das trotz seiner 32-Bit-Kompilierung 64-Bit-Ganzzahlen verwendet (im Gegensatz zu Rebol 2, bei dem 32-Bit-Ganzzahlen verwendet wurden).

Ich wollte sehen, was in CF Script passiert ist

<cfscript>
ttl = 0;

for (i=0;i LTE 1000000000 ;i=i+1) {
    ttl += i;
}
writeDump(ttl);
abort;
</cfscript>

Ich habe 5.00000000067E + 017

Dies war ein ziemlich ordentliches Experiment. Ich bin mir ziemlich sicher, dass ich das mit mehr Aufwand ein bisschen besser hätte codieren können.

ActivePerl v5.10.1 unter 32-Bit-Fenstern, Intel Core2duo 2.6:

$sum = 0;
for ($i = 0; $i <= 1000000000 ; $i++) {
  $sum += $i;
}
print $sum."\n";

Ergebnis: 5.00000000067109e + 017 in 5 Minuten.

Mit "use bigint" funktionierte das Skript zwei Stunden lang und würde mehr funktionieren, aber ich habe es gestoppt. Zu langsam.

Der Vollständigkeit halber in Clojure (schön, aber nicht sehr effizient):

(reduce + (take 1000000000 (iterate inc 1))) ; => 500000000500000000

AWK:

BEGIN { s = 0; for (i = 1; i <= 1000000000; i++) s += i; print s }

erzeugt das gleiche falsche Ergebnis wie PHP:

500000000067108992

Es scheint, dass AWK Gleitkomma verwendet, wenn die Zahlen wirklich groß sind, also ist zumindest die Antwort die richtige Größenordnung.

Testläufe:

$ awk 'BEGIN { s = 0; for (i = 1; i <= 100000000; i++) s += i; print s }'
5000000050000000
$ awk 'BEGIN { s = 0; for (i = 1; i <= 1000000000; i++) s += i; print s }'
500000000067108992

Kategorie andere interpretierte Sprache:

Tcl:

Wenn Sie Tcl 8.4 oder älter verwenden, hängt es davon ab, ob es mit 32 oder 64 Bit kompiliert wurde. (8.4 ist das Ende des Lebens).

Wenn Sie Tcl 8.5 oder eine neuere Version mit beliebigen großen Ganzzahlen verwenden, wird das richtige Ergebnis angezeigt.

proc test limit {
    for {set i 0} {$i < $limit} {incr i} {
        incr result $i
    }
    return $result
}
test 1000000000 

Ich habe den Test in einen Prozess eingefügt, um ihn bytekompiliert zu bekommen.

Für den PHP-Code lautet die Antwort hier :

Die Größe einer Ganzzahl ist plattformabhängig, obwohl ein Maximalwert von etwa zwei Milliarden der übliche Wert ist (das sind 32 Bit Vorzeichen). 64-Bit-Plattformen haben normalerweise einen Maximalwert von etwa 9E18. PHP unterstützt keine vorzeichenlosen Ganzzahlen. Die Ganzzahlgröße kann mit der Konstanten PHP_INT_SIZE und der Maximalwert mit der Konstanten PHP_INT_MAX seit PHP 4.4.0 und PHP 5.0.5 bestimmt werden.

Hafen:

proc Main()

   local sum := 0, i

   for i := 0 to 1000000000
      sum += i
   next

   ? sum

   return

Ergebnisse in 500000000500000000. (unter Windows / Mingw / x86 und OSX / Clang / x64)

Erlang arbeitet:

from_sum(From,Max) ->
    from_sum(From,Max,Max).
from_sum(From,Max,Sum) when From =:= Max ->
    Sum;
from_sum(From,Max,Sum) when From =/= Max -> 
    from_sum(From+1,Max,Sum+From).

Ergebnisse: 41> nutzlos: from_sum (1.1000000000). 500000000500000000

Lustige Sache, PHP 5.5.1 gibt 499999999500000000 (in ~ 30s), während Dart2Js 500000000067109000 gibt (was zu erwarten ist, da es JS ist, das ausgeführt wird). CLI Dart gibt die richtige Antwort ... sofort.

Erlang gibt auch das erwartete Ergebnis.

sum.erl:

-module(sum).
-export([iter_sum/2]).

iter_sum(Begin, End) -> iter_sum(Begin,End,0).
iter_sum(Current, End, Sum) when Current > End -> Sum;
iter_sum(Current, End, Sum) -> iter_sum(Current+1,End,Sum+Current).

Und damit:

1> c(sum).
{ok,sum}
2> sum:iter_sum(1,1000000000).
500000000500000000

Smalltalk:

(1 to: 1000000000) inject: 0 into: [:subTotal :next | subTotal + next ]. 

"500000000500000000"