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

[Clément David]

Hello all, 

 

Nice implementation ! IMHO `double()` might also be extended to support a
string, do you expect any other functions to be impacted by “string
interpretation” on type conversion ?

 

Thanks,

 

--

Clément

 

From: dev <dev-bounces at lists.scilab.org> On Behalf Of Antoine ELIAS
Sent: Saturday, October 27, 2018 8:29 PM
To: dev at lists.scilab.org
Subject: Re: [Scilab-Dev] Big literal integers for int64() and uint64()

 

Hello again,
I worked on it ( challenge accepted ! )

I took a look of your implementation, I'm not sure it is necessary to remove
trailing white spaces or inner spaces ( " 1 000 000 " is not a correct
representation of a number, that's all ! )
Or you have to manage "\t", "," or any localized separator.

In lot of language when you convert "123toto" you get 123 not an error.
And does not allow "1.123" is a mistake for me since uint64(1.123) ->
1(ui64).

I made an implementation in builtin for all (u)int functions that raises
error only on too long input string ("10000000000000000000" for example )
and empty string ( but we can convert to 0 like %nan )
I manage "nan", "NaN" "%nan", "inf", "Inf", "%inf", "-inf", "-Inf", "-%inf"
to respectively 0, minval and maxval
And "icing on the cake", is little bit faster than yours :p
(between 2 and 100 times depending of input size, C++ vs script)

(missing NRT, changes ... but it is Saturday ^^ )
https://codereview.scilab.org/#/c/20587/

Regards,
Antoine

Le 27/10/2018 à 17:34, Samuel Gougeon a écrit :

Hello Antoine,

Thanks for your answer.
I have opened a bug report #15837
<http://bugzilla.scilab.org/show_bug.cgi?id=15837>  about this topic.

About the overload:

Le 27/10/2018 à 14:00, Antoine ELIAS a écrit :

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.


In the report, i have posted a proposal for a working 11-rows-long
%c_uint64() overload (without the error messages ;)
With it, we get for instance

--> %c_uint64("9000000000000001000") + [ 1 -1001 ; 4 7]
 ans  =
  9000000000000001001  8999999999999999999
  9000000000000001004  9000000000000001007

whereas
--> uint64(9000000000000001000) + [ 1 -1001 ; 4 7]
 ans  =
  9000000000000001025  9000000000000000023
  9000000000000001028  9000000000000001031

It can process any relevant input array of any number of dimensions.

Best regards
Samuel






_______________________________________________
dev mailing list
dev at lists.scilab.org <mailto: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/20181030/bef2e167/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4425 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181030/bef2e167/attachment.p7s>