[Scilab-Dev] Big literal integers for int64() and uint64()

[Samuel Gougeon]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181027/81f406a2/attachment.htm>