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
--
https://mail.python.org/mailman/listinfo/python-list
