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@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
