Ich kann sogar berechnen ( expt 32768 32768 ) und ich habe:
476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656
Lisp schaltet automatisch math um, um ein bignum -Paket zu verwenden, wenn es so etwas sieht. Aber es gibt eine Einschränkung. Machen Sie Ihre Zahlen groß genug, und Sie können mehr Bits benötigen, um es darzustellen, als es Atome im bekannten Universum gibt. Dann wird Ihr Systemspeicher wahrscheinlich erschöpft sein. :)
Sie können einige Hinweise finden, indem Sie die Frage umdrehen: Warum gibt es eine Beschränkung für die Größe von Zahlen?
Es gibt einige praktische Gründe, die Größe von Zahlen zu begrenzen. Die Darstellung von Zahlen in bestimmten anderen Programmiersprachen ist eng mit der Hardwarearchitektur verbunden, wobei die Größe der Zahlen durch die Anzahl der Bits in den Registern des Prozessors begrenzt ist.
Glücklicherweise können Sie in Lisp normalerweise auf einer abstrakteren Ebene denken und den Programmierer von solchen Details auf niedriger Ebene befreien. Aber solche Arbitrary-arithmetische Berechnungen sind in der Regel langsamer als die Zahlen, die in die Prozessorregister passen.
PS: Überprüfen Sie auch, wie elegant Lisp mit Bruchteilen umgeht. Die Umwandlung von Brüchen in Fließkommazahlen erlaubt keine genaue Arithmetik. Zum Beispiel: (+ 1/3 2/7) = & gt; 13/21
Hier ist eine andere Perspektive.
Ein Grund für die Suche nach beliebigen Ganzzahlen ist, dass Lisp-Implementierungen, die effiziente, ungetastete Ganzzahlen haben, aber keine willkürliche Genauigkeits-Mathematik haben, im Vergleich zu anderen Sprachen auf derselben Plattform lahmgelegt sind.
Emacs Lisp packt ganze Zahlen in ein einzelnes Wort mit einem Typ-Tag ein, und weil es keine Bignum-Arithmetik hat (oder vielleicht gerade jetzt? Aber nicht an einem Punkt, auf jeden Fall), sind ganze Zahlen begrenzt zu etwas wie 28 Bits (auf einer 32-Bit-Plattform). Dies ist verkrüppelt im Vergleich zu C.
32 Bits sind verkrüppelt, aber 28 sind extra verkrüppelt. Es erschwert die Interoperabilität mit anderen Programmen. Zum Beispiel das Lesen binärer Strukturen, die 32-Bit-Ganzzahlen enthalten.
Zum Beispiel brach der GNU Emacs Newsreader (auf 32-Bit-Boxen) bei der Verbindung mit Servern, bei denen Artikelzahlen 28 Bit übergelaufen sind. Es lohnt sich also, Bignums zu haben, nur um 32 Bits zu bekommen.
Natürlich wurden Bignums nicht in Lisp eingeführt. Laut der Veröffentlichung Die Evolution von Lisp bignums wurden MacLisp erstmals 1970 oder 1971 hinzugefügt, weil einige Benutzer, die symbolische Mathematik mit Macsyma machten, diese benötigten.
Wenn Sie jedoch ein Lisp mit type-getaggten Ganzzahlen implementieren, werden Sie den Schmerz spüren und bignums implementieren wollen, nur um die Bits zu umgehen, die Sie für das Typ-Tag verloren haben.
Sie könnten dieses Problem lösen, indem Sie 32-Bit-Ganzzahlen fixieren, die gehäuft sind, und ungezählte, die 31, 30, ... 28 sind (was auch immer Ihre Tag-Größe ist). Aber das ist nur ein kleiner Gewinn für die Komplexität. Mit diesem Schema müssen Sie bereits alle Kombinationen in Ihren mathematischen Routinen bewältigen: Unboxed - Unboxed, Unboxed - Boxed, Boxed - Unboxed, usw. Mit etwas mehr Aufwand können Sie Bignums machen.
Geh bignum oder geh nach Hause, weißt du was ich meine? :)
Denk bignum, sei bignum!
Es braucht einen bignum Mann zuzugeben, dass er fixnum ist.
Gehen Sie (den Code, expandierende Makros) sanft und tragen Sie eine große Anzahl!
Je mehr Bignum sie sind, desto schwieriger werden sie.