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-boun...@lists.scilab.org> On Behalf Of Antoine ELIAS
Sent: Saturday, October 27, 2018 8:29 PM
To: dev@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@lists.scilab.org <mailto:dev@lists.scilab.org>
http://lists.scilab.org/mailman/listinfo/dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev mailing list dev@lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev
