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

[Antoine ELIAS]

Hello Samuel,

Currently, parser ... lexer, in fact, try to read "number" and convert 
it to floating point number, at this moment, we have no idea what the 
final goal of this number.
After that, the parser try to understand what to do with this number 
(already a double).
So I think the first case is not possible with the current management of 
numbers.

For string argument, I think it cannot be done easily in an overload 
macro for the same reason.
But it can be done in (u)int builtin .

Regards,
Antoine
Le 27/10/2018 à 01:06, Samuel Gougeon a écrit :
>
> 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 at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev

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