Entering a very large number

[Richard Damon]

On 3/26/18 6:45 AM, bartc wrote:
> On 26/03/2018 03:35, Richard Damon wrote:
>> On 3/25/18 9:37 PM, bartc wrote:
>
>>> So the overhead /can/ be substantial, and /can/ be significant 
>>> compared with doing bignum calculations.
>>>
>>> Of course, once initialised, C might be used a hundred times, then 
>>> the overhead is less significant. But it is not small enough to just 
>>> dismiss.
>>>
>> And my point is that writing a program to just add or multiply once 
>> two FIXED big long numbers (since they are in the source code, that 
>> seems fixed), a million times seems  unlikely (and even then the cost 
>> isn't that bad, since that sounds like a run once program).
>
> Similar overheads occur when you use string=>int even on small numbers:
>
> This code:
>
>     C = int("12345")
>     D = C+C      # or C*C; about the same results
>
> takes 5 times as long (using my CPython 3.6.x on Windows) as:
>
>     C = 12345
>     D = C+C
>
> Your arguments that this doesn't really matter would equally apply here.
>
> Yet you don't see Python code full of 'int("43")' instead of just '43' 
> on the basis that the extra overhead is not significant, as the 
> program might be run only once.
>
> A slightly worrying attitude in a language that has issues with 
> performance, but no longer a surprising one.
>
Strawman. The original argument was that there was sufficient clarity 
grounds to want to express the big number as a string. That base 
argument doesn't hold here, and in fact for small number the construct 
clearly makes the code less clear, so the construct fails there. If the 
numbers were formatted in a way that using a string, and doing some 
manipulations on it first, and then converting made sense, you might be 
able to make the argument, but then again it comes down to efficiency vs 
clarity, and for that, as long as efficiency hasn't suffered enough to 
start to become a correctness issue, clarity has an edge.

-- 
Richard Damon