Same issue with uint64 and int64:
Apparently these variable types have only 53 bits of precision. This is the number of significands in double precision format, so it seems that uint64 is implemented in FreeMat as a kind of emulated uint64 actually using double precision that behaves like uint64 but lacks its precision.
Examples:
--> (uint64(2^53)-1) - (uint64(2^53)-1000) % This gives a correct result ans = 999 --> (uint64(2^54)-1) - (uint64(2^54)-1000) % This gives a wrong result result ans = 1000 --> (uint64(2^57)-1) - (uint64(2^57)-1000) % This gives a wrong result result ans = 992 --> (uint64(2^59)-1) - (uint64(2^59)-1000) % This gives a wrong result result ans = 1024
Same problem with int64:
--> (int64(2^53)-1) - (int64(2^53)-1000) % This gives a correct result ans = 999 --> (int64(2^54)-1) - (int64(2^54)-1000) % This gives a wrong result result ans = 1000
Bug found in FreeMat v4.0 (Linux) and 4.1.1 (Windows).
This leads to unexpected results. The actual reason for using uint64 in the first place is because the accuracy of 53 bits of double is not sufficient. So uint64 should be a true 64bit type. Alternatively, it should be clearly written in the documentation that there is a restriction and that accuracy is only given for up to 53 bits, i.e. 2^53-1.
Last edit: Michael 2015-11-23