我甚至可以计算（expt 32768 32768）而且我得到了：
476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656
答案 0 :(得分：12)
当Lisp看到这种事情时，会自动切换数学以使用bignum包。但是有一个限制。使你的数字足够大，你可能需要更多的位来表示它，而不是已知宇宙中的原子。那么你的系统内存可能会耗尽。 ：）
答案 1 :(得分：9)
你可以通过提出问题找到一些线索：为什么对数字大小有限制？
限制数字大小有一些实际原因。某些其他编程语言中数字的表示与硬件架构密切相关，数字大小受处理器寄存器中位数的限制。
幸运的是，在Lisp中，您通常可以在更抽象的层面上思考，从而将程序员从如此低级别的细节中解放出来。但是这样的arbitrary-precision arithmetic通常比限制数字更慢以适应处理器寄存器。
PS：还要看看Lisp处理分数的优雅程度。不将分数转换为浮点数允许精确的算术。例如：(+ 1/3 2/7) =＆gt; 13/21
答案 2 :(得分：3)
这是另一个观点。
想要任意精度整数的一个原因是，与同一平台上的其他语言相比，具有高效的，未装箱的整数但没有任意精度数学的Lisp实现会瘫痪。
Emacs Lisp将整数打包成一个带有类型标记的单词，并且因为它没有bignum算术（或者现在可能没有？但在任何情况下都没有），整数是有限的类似于28位（在32位平台上）。与C相比，这是瘫痪的。
32位是残废的，但28位是残缺的。它使得与其他程序的互操作性很难。例如，读取包含32位整数的二进制结构。
例如，当连接到文章编号溢出28位的服务器时，GNU Emacs新闻阅读器（在32位框上）断开。因此，让bignums达到32位是值得的。
这当然不是为什么将bignums引入Lisp的原因。根据文章 Lisp的演变 bignums在1970年或1971年首次被添加到MacLisp，因为一些用Macsyma进行符号数学的用户需要它。
但是如果你正在使用带有类型标记的整数实现一个Lisp，你会感到痛苦并想要实现bignums只是为了绕过你丢失到类型标记的位。
你可以通过固定32位整数来解决这个问题，而未装箱的是31,30，... 28（无论你的标签大小是多少）。但这对于复杂性来说收效甚微。使用该方案，您必须处理数学例程中的所有组合：unboxed - unboxed，unboxed - boxed，boxed - unboxed等。通过更多的努力，你可以做bignums。
去bignum或回家，知道我的意思吗？ ：）
想想bignum，是bignum！
需要一个bignum男人承认他是固定的。
轻轻地走（代码，扩展宏），携带一个大数字！
他们的bignum越多，他们就会越难。