Entering a very large number

[Richard Damon]

On 3/26/18 6:31 AM, bartc wrote:
> On 26/03/2018 10:34, Steven D'Aprano wrote:
>> On Mon, 26 Mar 2018 02:37:44 +0100, bartc wrote:
>
>>> If I instead initialise C using 'C = int("288712...")', then timings
>>> increase as follows:
>>
>> Given that the original number given had 397 digits and has a bit length
>> of 1318, I must admit to some curiosity as to how exactly you managed to
>> cast it to a C int (32 bits on most platforms).
>>
>> It is too big for an int, a long (64 bits), a long-long (128 bits) or
>> even a long-long-long-long-long-long-long-long-long-long-long-long-long-
>> long-long-long (1024 bits), if such a thing even exists.
>>
>>
>> So what exactly did you do?
>
> I'm not sure why you think the language C came into it. I did this:
>
> def fn():
>     C = int(
>     "28871482380507712126714295971303939919776094592797"
>     "22700926516024197432303799152733116328983144639225"
>     "94197780311092934965557841894944174093380561511397"
>     "99994215424169339729054237110027510420801349667317"
>     "55152859226962916775325475044445856101949404200039"
>     "90443211677661994962953925045269871932907037356403"
>     "22737012784538991261203092448414947289768854060249"
>     "76768122077071687938121709811322297802059565867")
>
> #   C = 2887148238050771212671429... [truncated for this post]
>
>     D=C+C
>
> for i in range(1000000):
>     fn()
>
> The purpose was to establish how such int("...") conversions compare 
> in overheads with actual arithmetic with the resulting numbers.
>
Of course if this was done in C with a version that had builtin bignum 
ints or an aggresive enough optimizer (or a Python that did a similar 
level of optimizations) this function would just test the speed of 
starting the program, as it actually does nothing and can be optimized 
away. Yes, something like this can beused to measure the base time to do 
something, but the real question should be is that time significant 
compared to the other things that the program is doing, Making a 200x 
improvement on code that takes 1% of the execution time saves you 
0.995%, not normally worth it unless your program is currently running 
at 100.004% of the allowed (or acceptable) timing, if acceptable timing 
can even be defined that precisely.

-- 
Richard Damon