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?
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:
In computer science, arbitrary-precision arithmetic is a technique whereby calculations are performed on numbers whose digits of precision are limited only by the available memory of the host system. This contrasts with the faster fixed-precision arithmetic found in most ALU hardware, which typically offers between 6 and 16 decimal digits. It is also called bignum arithmetic, and sometimes even "infinite-precision arithmetic" (which is a misnomer, since the number of digits is both finite and bounded in practice).
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.