Java 在Clojure中，默认十进制文字不是BigDecimal类型有什么原因吗？

我了解到Clojure reader将带有后缀“M”的十进制文字（如1.23M）解释为BigDecimal。我还知道，不带“M”的十进制数变成了Java双精度数。
但我认为正常的十进制数最好是BigDecimal，并且依赖于主机的十进制数有后缀，比如1.23H。因此，当数字由于IEEE double的精度限制而损坏或截断时，我们很容易注意到数字的精度有限。另外，我认为更简单的表达式应该是独立于主机的。

---

除了时间性能之外，Clojure还有什么理由将文字十进制解释为JavaDouble吗？另外，我不认为时间性能是一个答案，因为它不是C/C++，其他声明依赖于主机的十进制的方法可以像“1.23H”一样实现。

性能可能是一回事。也许

clojure.core

开发人员可以插话说明原因

我个人认为默认情况下不使用bigdecimal并没有什么大不了的，因为：

• 正如您所指出的，这里有一个字面意思：

  M

• 有像…这样的操作。。。（请注意引号）表示“支持任意精度”

---

对于整数，Clojure会在需要时自动升级到更大的大小。这已更改，以便引发溢出异常。从远处看，我的感觉是：
• Clojure是一种实用的语言，在实际的时间内做实际的事情。他们不希望性能崩溃，因为数字操作意外地使用了任意精度库，而不是CPU整数操作。相比之下，该方案似乎将数学的精确性置于实用性之上
• 人们不喜欢在运行时惊讶于inter-op调用会失败，因为Java库期望的是32位整数而不是任意大小的整数
因此，我们决定默认使用普通整数（我认为Java longs？），并且仅在程序员要求时使用任意大的整数，当程序员在知情的情况下决定他们愿意接受性能影响和操作间影响时使用任意大的整数

---

我的猜测与对小数点的数字所做的决定类似。
我注意到clojure会自动使用

*'

将long升级为BigInt。然而，当我键入

（*'1e200 1e200）

和

（*'1e-200 1e-200）

时，repl只说

无限

和

0.0

。为什么那些自动升级的函数不支持双精度类型？这里来晚了，但这是因为

1e200

是浮点常量而不是整数。如果要执行此乘法，可以将浮点值转换为BigInt:

（*”（BigInt 1e200）（BigInt 1e200））

，从而生成

1（400个零）N

。