On Fri, Mar 30, 2018 at 9:30 PM, bartc wrote:
> On 26/03/2018 16:31, Chris Angelico wrote:
>> Yeah. It's so annoying that compilers work so hard to make your code
>> fast, when all you want to do is measure exactly how slow it is.
>> Compiler authors are stupid.
>
>
> In some ways, yes they are. I
On 3/30/18 6:41 AM, bartc wrote:
On 27/03/2018 04:49, Richard Damon wrote:
On 3/26/18 8:46 AM, bartc wrote:
Hence my testing with CPython 3.6, rather than on something like
PyPy which can give results that are meaningless. Because, for
example, real code doesn't repeatedly execute the same p
On 27/03/2018 04:49, Richard Damon wrote:
On 3/26/18 8:46 AM, bartc wrote:
Hence my testing with CPython 3.6, rather than on something like PyPy
which can give results that are meaningless. Because, for example,
real code doesn't repeatedly execute the same pointless fragment
millions of tim
On 26/03/2018 16:31, Chris Angelico wrote:
On Mon, Mar 26, 2018 at 11:46 PM, bartc wrote:
On 26/03/2018 13:30, Richard Damon wrote:
On 3/26/18 6:31 AM, bartc wrote:
The purpose was to establish how such int("...") conversions compare in
overheads with actual arithmetic with the resulting
On Mon, 26 Mar 2018 23:49:07 -0400, Richard Damon wrote:
> The bigger issue is that these sort of micro-measurements aren't
> actually that good at measuring real quantitative performance costs.
> They can often give qualitative indications, but the way modern
> computers work, processing environm
On 3/26/18 8:46 AM, bartc wrote:
On 26/03/2018 13:30, Richard Damon wrote:
On 3/26/18 6:31 AM, bartc wrote:
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 tha
Am 26.03.18 um 12:31 schrieb bartc:
On 26/03/2018 10:34, Steven D'Aprano wrote:
So what exactly did you do?
I did this:
def fn():
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"941977803110929349655578418
On Mon, Mar 26, 2018 at 11:46 PM, bartc wrote:
> On 26/03/2018 13:30, Richard Damon wrote:
>>
>> On 3/26/18 6:31 AM, bartc wrote:
>
>
>>> The purpose was to establish how such int("...") conversions compare in
>>> overheads with actual arithmetic with the resulting numbers.
>>>
>> Of course if thi
Steven D'Aprano writes:
> 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 t
On 26/03/2018 13:30, Richard Damon wrote:
On 3/26/18 6:31 AM, bartc wrote:
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 a
On Mon, 26 Mar 2018 11:45:33 +0100, bartc wrote:
> 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
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
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 overhea
On Mon, 26 Mar 2018 11:31:22 +0100, bartc wrote:
> On 26/03/2018 10:34, Steven D'Aprano wrote:
>> So what exactly did you do?
>
> I'm not sure why you think the language C came into it.
My misunderstanding. Sorry.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
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 n
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 curios
On Mon, 26 Mar 2018 02:37:44 +0100, bartc wrote:
> Calling a function that sets up C using 'C = 288714...' on one line, and
> that then calculates D=C+C, takes 0.12 seconds to call 100 times.
>
> To do D=C*C, takes 2.2 seconds (I've subtracted the function call
> overhead of 0.25 seconds; the
On Monday, March 26, 2018 at 12:55:43 AM UTC+5:30, Peter J. Holzer wrote:
> On 2018-03-25 19:18:23 +0200, ast wrote:
> > Le 25/03/2018 à 03:47, Steven D'Aprano a écrit :
> > > The Original Poster (OP) is concerned about saving, what, a tenth of a
> > > microsecond in total? Hardly seems worth the e
On 3/25/18 9:37 PM, bartc wrote:
On 26/03/2018 00:27, Richard Damon wrote:
On 3/25/18 8:32 AM, bartc wrote:
Using CPython on my machine, doing a string to int conversion that
specific number took 200 times as long as doing a normal assignment.
That conversion took 4 microseconds.
Not signi
On 26/03/2018 00:27, Richard Damon wrote:
On 3/25/18 8:32 AM, bartc wrote:
Using CPython on my machine, doing a string to int conversion that
specific number took 200 times as long as doing a normal assignment.
That conversion took 4 microseconds.
Not significant if it's only done once. But
On 3/25/18 8:32 AM, bartc wrote:
On 25/03/2018 02:47, Steven D'Aprano wrote:
On Sun, 25 Mar 2018 00:05:56 +0100, Peter J. Holzer wrote:
[...]
yes, good idea
Not if you want to avoid that string to int conversion (as you stated).
That is still there, but in addition you now split the string
On 2018-03-25 19:18:23 +0200, ast wrote:
> Le 25/03/2018 à 03:47, Steven D'Aprano a écrit :
> > The Original Poster (OP) is concerned about saving, what, a tenth of a
> > microsecond in total? Hardly seems worth the effort, especially if you're
> > going to end up with something even slower.
> >
>
Le 25/03/2018 à 03:47, Steven D'Aprano a écrit :
On Sun, 25 Mar 2018 00:05:56 +0100, Peter J. Holzer wrote:
The Original Poster (OP) is concerned about saving, what, a tenth of a
microsecond in total? Hardly seems worth the effort, especially if you're
going to end up with something even sl
On 25/03/2018 16:47, Grant Edwards wrote:
On 2018-03-25, bartc wrote:
On 25/03/2018 02:47, Steven D'Aprano wrote:
The Original Poster (OP) is concerned about saving, what, a tenth of a
microsecond in total? Hardly seems worth the effort, especially if you're
going to end up with something eve
bartc writes:
> On 25/03/2018 15:53, Joe Pfeiffer wrote:
>> ast writes:
>
>>> C = int(
>>> "28871482380507712126714295971303939919776094592797"
>>> "22700926516024197432303799152733116328983144639225"
>>> "94197780311092934965557841894944174093380561511397"
>>> "42154241693397290542371100275
On 2018-03-25, bartc wrote:
> On 25/03/2018 02:47, Steven D'Aprano wrote:
>
>> The Original Poster (OP) is concerned about saving, what, a tenth of a
>> microsecond in total? Hardly seems worth the effort, especially if you're
>> going to end up with something even slower.
>
> Using CPython on my
On 25/03/2018 15:53, Joe Pfeiffer wrote:
ast writes:
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"94197780311092934965557841894944174093380561511397"
"4215424169339729054237110027510420801349667317"
"551528592269629167
On 3/25/2018 10:53 AM, Joe Pfeiffer wrote:
After following the thread for a while... you will, of course, simply
have to do a string to int conversion no matter what approach you take
to writing it. The number is a string of digits; it has to be converted
to the internal representation. Even i
On 25/03/2018 15:01, Christian Gollwitzer wrote:
Am 25.03.18 um 14:32 schrieb bartc:
Using CPython on my machine, doing a string to int conversion that
specific number took 200 times as long as doing a normal assignment.
That conversion took 4 microseconds.
Not significant if it's only done o
ast writes:
> Hi
>
> I found this way to put a large number in
> a variable.
>
> C = int(
> "28871482380507712126714295971303939919776094592797"
> "22700926516024197432303799152733116328983144639225"
> "94197780311092934965557841894944174093380561511397"
> "42154241693397290542371100275104208
Am 25.03.18 um 14:32 schrieb bartc:
Using CPython on my machine, doing a string to int conversion that
specific number took 200 times as long as doing a normal assignment.
That conversion took 4 microseconds.
Not significant if it's only done once. But it might be executed a
million times.
On 25/03/2018 02:47, Steven D'Aprano wrote:
On Sun, 25 Mar 2018 00:05:56 +0100, Peter J. Holzer wrote:
[...]
yes, good idea
Not if you want to avoid that string to int conversion (as you stated).
That is still there, but in addition you now split the string into a
list and then join the list
On Sun, 25 Mar 2018 00:05:56 +0100, Peter J. Holzer wrote:
[...]
>> yes, good idea
>
> Not if you want to avoid that string to int conversion (as you stated).
>
> That is still there, but in addition you now split the string into a
> list and then join the list into a different string.
I'm glad
On 2018-03-23 14:12:27 +0100, ast wrote:
> Le 23/03/2018 à 13:55, Wolfgang Maier a écrit :
> > On 03/23/2018 01:30 PM, Wolfgang Maier wrote:
> > > On 03/23/2018 01:16 PM, ast wrote:
[quoted from the first mail in this thread:]
> > > > It works but is it not optimal since there is a
> > > > string
On 2018-03-23 14:01, ast wrote:
> Le 23/03/2018 à 13:43, Rustom Mody a écrit :
>> On Friday, March 23, 2018 at 5:46:56 PM UTC+5:30, ast wrote:
>>> Hi
>>>
>>> I found this way to put a large number in
>>> a variable.
>>
>> What stops you from entering the number on one single (v long) line?
>
>
>
On 3/23/18 9:35 AM, ast wrote:
Le 23/03/2018 à 14:16, Antoon Pardon a écrit :
On 23-03-18 14:01, ast wrote:
Le 23/03/2018 à 13:43, Rustom Mody a écrit :
On Friday, March 23, 2018 at 5:46:56 PM UTC+5:30, ast wrote:
What meaningful information from number can you easily retrieve from
represe
On 23-03-18 14:35, ast wrote:
> Le 23/03/2018 à 14:16, Antoon Pardon a écrit :
>> On 23-03-18 14:01, ast wrote:
>>> Le 23/03/2018 à 13:43, Rustom Mody a écrit :
On Friday, March 23, 2018 at 5:46:56 PM UTC+5:30, ast wrote:
>
>
>> What meaningful information from number can you easily retrieve f
Le 23/03/2018 à 14:16, Antoon Pardon a écrit :
On 23-03-18 14:01, ast wrote:
Le 23/03/2018 à 13:43, Rustom Mody a écrit :
On Friday, March 23, 2018 at 5:46:56 PM UTC+5:30, ast wrote:
What meaningful information from number can you easily retrieve from
representing the number in some kind of
Le 23/03/2018 à 13:55, Wolfgang Maier a écrit :
On 03/23/2018 01:30 PM, Wolfgang Maier wrote:
On 03/23/2018 01:16 PM, ast wrote:
n = int(
''.join("""
37107287533902102798797998220837590246510135740250
46376937677490009712648124896970078050417018260538
74324986199524741059474233309513058
On 23-03-18 14:01, ast wrote:
> Le 23/03/2018 à 13:43, Rustom Mody a écrit :
>> On Friday, March 23, 2018 at 5:46:56 PM UTC+5:30, ast wrote:
>>> Hi
>>>
>>> I found this way to put a large number in
>>> a variable.
>>
>> What stops you from entering the number on one single (v long) line?
>
>
> It i
On 23.03.2018 14:01, ast wrote:
> It is not beautiful and not very readable. It is better to
> have a fixed number of digits per line (eg 50)
Oh yes, because clearly a 400-digit number becomes VERY beautiful and
readable once you add line breaks to it.
Cheers,
Joe
--
>> Wo hattest Du das Beben
Le 23/03/2018 à 13:30, Wolfgang Maier a écrit :
On 03/23/2018 01:16 PM, ast wrote:
A very simple improvement would be to use a single
triple-quoted string. Assuming you are copy/pasting
the number from somewhere that will save a lot of your
time.
no, it seems that sone \n are inserted insid
Le 23/03/2018 à 13:43, Rustom Mody a écrit :
On Friday, March 23, 2018 at 5:46:56 PM UTC+5:30, ast wrote:
Hi
I found this way to put a large number in
a variable.
What stops you from entering the number on one single (v long) line?
It is not beautiful and not very readable. It is better to
On 03/23/2018 01:30 PM, Wolfgang Maier wrote:
On 03/23/2018 01:16 PM, ast wrote:
Hi
I found this way to put a large number in
a variable.
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"9419778031109293496555784189494417409338
On Friday, March 23, 2018 at 5:46:56 PM UTC+5:30, ast wrote:
> Hi
>
> I found this way to put a large number in
> a variable.
What stops you from entering the number on one single (v long) line?
In case there is a religious commitment to PEP 8 dicta, the recommended
meditation is this line (als
On 03/23/2018 01:16 PM, ast wrote:
Hi
I found this way to put a large number in
a variable.
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"94197780311092934965557841894944174093380561511397"
"421542416933972905423711002751
Hi
I found this way to put a large number in
a variable.
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"94197780311092934965557841894944174093380561511397"
"4215424169339729054237110027510420801349667317"
"55152859226962916
47 matches
Mail list logo