Hello,
Here is an awkward case. I am afraid that it won't be possible to
improve the situation, but let's see it:
--> int64(461168601842738791)
ans =
461168601842738816 <<< ..38816 =/= ..38791
I know that this comes from the fact that the literal 461168601842738791
is /by default /parsed as the decimal number 461168601842738791., and
since 1/461168601842738791 < %eps, there is a round-off error, after
what the "truncated" decimal number is converted into an int64.
So, the question is: in the specific cases of int64() and uint64(),
would it be possible to parse literals input arguments assuming that
they are not decimal?
Before parsing the literal, could the parser be aware that the calling
function is int64() or uint64()?
Another solution -- may be easier to implement -- to provide literal
numbers to int64() and uint64() without rounding them could be to
support string inputs, as for instance hex2dec() does it. It is
presently not the case, and the overloading is not enabled:
--> int64("461168601842738791")
int64: Wrong type for input argument #1: integer, boolean or double
expected.
Samuel
_______________________________________________
dev mailing list
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
