Erlang长64号BUG
如果操作数之一不够大，Erlang 就会截断大长操作的值。 尽管如果两个操作数都足够大，则不会截断。
199> 3656626623097354252900000 * 11111111111111111111111111.
40629184701081713921111110704819264100293971900000
200> 3656626623097354252900000 * 64.
234024103878230672185600000
有什么线索吗？或者说这确实是一个BUG？
Erlang is truncating the value of big long operations if one of the operands are not big enough.
Although it is not truncating if both operands are big enough.
199> 3656626623097354252900000 * 11111111111111111111111111.
40629184701081713921111110704819264100293971900000
200> 3656626623097354252900000 * 64.
234024103878230672185600000
Any clue why? Or it is really a BUG?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
刚刚使用 GHCI（格拉斯哥哈斯克尔解释器）尝试了这两个操作，它返回了完全相同的结果。
不确定您是否意识到这一点，但 Erlang 支持 bignums：
Just tried both operations using GHCI (The Glasgow Haskell Interpreter) and it gave back exactly the same result.
Not sure if you are aware of this, but Erlang supports bignums:
这不是一个错误。 Erlang 具有任意精度的整数。 （实际上，这当然受到机器上可用内存的限制......）
这些整数是使用称为“fixnum”和“bignum”的东西来实现的。 Fixnum 是适合 32 位架构上的 28 位或 64 位架构上的 60 位的（有符号）整数。附加位用于类型标记（请记住，Erlang 是动态强类型的，因此需要对其值进行类型标记）。然后，Erlang 虚拟机切换到大于该大小的 bignum。这些措施的实施效率要低得多。
除了保持在固定数范围内之外，添加 HiPE 编译，程序的算术部分应该具有“接近 C 的速度”。
This is not a bug. Erlang has arbitrary precision integers. (In practice this is limited by the available memory on the machine of course...)
These integers are implemented using something called "fixnum" and "bignum". Fixnums are (signed) integers fitting 28 bits on 32 bit architecture or 60 bits on a 64 bit architecture. The additional bits are used for type tagging (remember that Erlang is dynamically strongly typed and thus needs type tags on its values). The Erlang virtual machine then switches to bignum above that size. These are far less efficiently implemented.
Add HiPE compilation on top of staying within the fixnum range and you should have "close to C speed" for the arithmetic parts of the program.