Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #41836 > unrolled thread

Re: Performance of int/long in Python 3

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-03-25 16:16 -0700
    Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-26 00:17 +0000
      Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-26 11:28 +1100
      Re: Performance of int/long in Python 3 Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-03-26 00:49 +0000
      Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-03-25 20:55 -0400
        Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-26 05:01 +0000
          Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-26 17:12 +1100
          Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-03-26 09:18 -0400

#41836 — Re: Performance of int/long in Python 3

On 03/25/2013 02:51 PM, Chris Angelico wrote:
> Python 3's int is faster than Python 2's long, but slower than Python
> 2's int. So the question really is, would a two-form representation be
> beneficial, and if so, is it worth the coding trouble?

I'm inclined to say it's not worth the trouble.  If you're working with numbers, and speed is an issue, you really 
should be using one of the numeric or scientific packages out there.

--
~Ethan~

[toc] | [next] | [standalone]

#41840

On Mon, 25 Mar 2013 16:16:05 -0700, Ethan Furman wrote:

> On 03/25/2013 02:51 PM, Chris Angelico wrote:
>> Python 3's int is faster than Python 2's long, but slower than Python
>> 2's int. So the question really is, would a two-form representation be
>> beneficial, and if so, is it worth the coding trouble?
> 
> I'm inclined to say it's not worth the trouble.  If you're working with
> numbers, and speed is an issue, you really should be using one of the
> numeric or scientific packages out there.


Or PyPy, which will probably optimize it just fine.

Also, speaking as somebody who remembers a time when ints where not 
automatically promoted to longs (introduced in, Python 2.2, I think?) let 
me say that having a single unified int type is *fantastic*, and managing 
ints/longs by hand is a right royal PITA.

What I would like to see though is a module where I can import fixed-
width signed and unsigned integers that behave like in C, complete with 
overflow, for writing code that matches the same behaviour as other 
languages.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#41841

On Tue, Mar 26, 2013 at 11:17 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Also, speaking as somebody who remembers a time when ints where not
> automatically promoted to longs (introduced in, Python 2.2, I think?) let
> me say that having a single unified int type is *fantastic*, and managing
> ints/longs by hand is a right royal PITA.

Oh, I absolutely agree! I'm just looking at performance here, but
definitely the int/long unification is a Good Thing.

ChrisA

[toc] | [prev] | [next] | [standalone]

#41842

On 26 March 2013 00:17, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 25 Mar 2013 16:16:05 -0700, Ethan Furman wrote:
>
[snip]
>> If you're working with
>> numbers, and speed is an issue, you really should be using one of the
>> numeric or scientific packages out there.
>
[snip]
> What I would like to see though is a module where I can import fixed-
> width signed and unsigned integers that behave like in C, complete with
> overflow, for writing code that matches the same behaviour as other
> languages.

Numpy can do this:

>>> import numpy
>>> a = numpy.array([0], numpy.uint32)
>>> a
array([0], dtype=uint32)
>>> a[0] = -1
>>> a
array([4294967295], dtype=uint32)

Unfortunately it doesn't work with numpy "scalars", so to use this
without the index syntax you'd need a wrapper class. Also it uses
Python style floor rounding rather than truncation as in C (actually I
seem to remember discovering that in C this is implementation
defined).

Presumably ctypes has something like this as well.


Oscar

[toc] | [prev] | [next] | [standalone]

#41843

In article <5150e900$0$29998$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Also, speaking as somebody who remembers a time when ints where not 
> automatically promoted to longs (introduced in, Python 2.2, I think?) let 
> me say that having a single unified int type is *fantastic*,

And incredibly useful when solving Project Euler problems :-)

[I remember when strings didn't have methods]

[toc] | [prev] | [next] | [standalone]

#41852

On Mon, 25 Mar 2013 20:55:03 -0400, Roy Smith wrote:

> In article <5150e900$0$29998$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
>> Also, speaking as somebody who remembers a time when ints where not
>> automatically promoted to longs (introduced in, Python 2.2, I think?)
>> let me say that having a single unified int type is *fantastic*,
> 
> And incredibly useful when solving Project Euler problems :-)
> 
> [I remember when strings didn't have methods]

No string methods? You were lucky. When I were a lad, you couldn't even 
use "" delimiters for strings.

>>> "b string"
Parsing error: file <stdin>, line 1:
"b string"
 ^
Unhandled exception: run-time error: syntax error


Python 0.9.1.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#41853

On Tue, Mar 26, 2013 at 4:01 PM, Steven D'Aprano > No string methods?
You were lucky. When I were a lad, you couldn't even
> use "" delimiters for strings.
>
>>>> "b string"
> Parsing error: file <stdin>, line 1:
> "b string"
>  ^
> Unhandled exception: run-time error: syntax error
>
>
> Python 0.9.1.

Well of course that's an error. Anyone can see it should have been:
>>> "a string"

*duck*

ChrisA

[toc] | [prev] | [next] | [standalone]

#41899

In article <51512bb5$0$29973$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Mon, 25 Mar 2013 20:55:03 -0400, Roy Smith wrote:
> 
> > In article <5150e900$0$29998$c3e8da3$5496439d@news.astraweb.com>,
> >  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> > 
> >> Also, speaking as somebody who remembers a time when ints where not
> >> automatically promoted to longs (introduced in, Python 2.2, I think?)
> >> let me say that having a single unified int type is *fantastic*,
> > 
> > And incredibly useful when solving Project Euler problems :-)
> > 
> > [I remember when strings didn't have methods]
> 
> No string methods? You were lucky. When I were a lad, you couldn't even 
> use "" delimiters for strings.
> 
> >>> "b string"
> Parsing error: file <stdin>, line 1:
> "b string"
>  ^
> Unhandled exception: run-time error: syntax error
> 
> 
> Python 0.9.1.

OK, you've got me beat.  For Python.  Am I going to have to go dig out 
my old IBM-1130 assembler decks?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web