
<html>

  <head>


    <meta http-equiv="content-type" content="text/html; charset=utf-8">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <p>Hello,</p>

    <p>Here is an awkward case. I am afraid that it won't be possible to

      improve the situation, but let's see it:</p>

    <tt>--> int64(461168601842738791)</tt><tt><br>

    </tt>

    <p><tt> ans  =</tt><tt><br>

      </tt><tt>  461168601842738816   <<< ..38816 =/= ..38791</tt><tt><br>

      </tt><font face="Arial"><br>

      </font>I know that this comes from the fact that the literal <tt>461168601842738791</tt>

      is <i>by default </i>parsed as the decimal number <tt>461168601842738791.</tt>,

      and since <tt>1/461168601842738791 < %eps</tt>, there is a

      round-off error, after what the "truncated" decimal number is

      converted into an int64.<br>

      <br>

      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?</p>

    <p>Before parsing the literal, could the parser be aware that the

      calling function is int64() or uint64()?</p>

    <p>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:</p>

    <p><tt>--> int64("</tt><tt><tt>461168601842738791</tt>")<br>

        int64: Wrong type for input argument #1: integer, boolean or

        double expected.</tt></p>

    Samuel

    <p><br>

    </p>

  </body>

</html>