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
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
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
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
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
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
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"
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.
>>>
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
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
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
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
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
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
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;
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
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
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.
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
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
bartc writes:
> On 25/03/2018 15:53, Joe Pfeiffer wrote:
>> ast writes:
>
>>> C = int(
>>> "28871482380507712126714295971303939919776094592797"
>>> "22700926516024197432303799152733116328983144639225"
>>> "94197780311092934965557841894944174093380561511397"
>>>
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.
>
>
On 25/03/2018 15:53, Joe Pfeiffer wrote:
ast writes:
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"94197780311092934965557841894944174093380561511397"
"4215424169339729054237110027510420801349667317"
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
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
ast writes:
> Hi
>
> I found this way to put a large number in
> a variable.
>
> C = int(
> "28871482380507712126714295971303939919776094592797"
> "22700926516024197432303799152733116328983144639225"
> "94197780311092934965557841894944174093380561511397"
>
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
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
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
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
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
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
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
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
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
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
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"
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
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"
Hi
I found this way to put a large number in
a variable.
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"94197780311092934965557841894944174093380561511397"
"4215424169339729054237110027510420801349667317"
47 matches
Mail list logo