On Sep 2, 12:51 pm, [EMAIL PROTECTED] wrote:
... right-angled triangle puzzle solver
max = 0
maxIndex = 0
index = 0
for solution in solutions:
if solution max:
max = solution
maxIndex = index
index += 1
print maxIndex
Not that it solves your slowness problem,
Neil Cerutti [EMAIL PROTECTED] writes:
On 2007-09-02, Steven D'Aprano
[EMAIL PROTECTED] wrote:
A big question mark in my mind is Lisp, which according to
aficionados is just as dynamic as Python, but has native
compilers that generate code running as fast as highly
optimized C.
Lisp, as
On 2007-09-11, Robert Brown [EMAIL PROTECTED] wrote:
Neil Cerutti [EMAIL PROTECTED] writes:
On 2007-09-02, Steven D'Aprano
[EMAIL PROTECTED] wrote:
A big question mark in my mind is Lisp, which according to
aficionados is just as dynamic as Python, but has native
compilers that generate
Steven D'Aprano [EMAIL PROTECTED] writes: A big
question mark in my mind is Lisp, which according to aficionados is
just as dynamic as Python, but has native compilers that generate
code running as fast as highly optimized C. I'm not qualified to
judge whether the lessons learnt from Lisp can
Thanks for all the answers to my question. I think what I need to take
away from this is that xrange is an object - I thought it was just
some loop construct, and that maths is slow in python - so avoid
pathological looping.I remember the first time I tried Objective-C on
OS X I used the NSNumber
On 3 Sep, 15:39, [EMAIL PROTECTED] wrote:
Thanks for all the answers to my question. I think what I need to take
away from this is that xrange is an object
Indeed, but using xrange can be faster than converting your for
loops to while loops plus a counter; I converted your code to use
the
Martin v. Löwis a écrit :
(2) it is a interpretation language
Not quite. It's compiled to byte-code - just like Java (would you call
Java an 'interpreted language' ?)
Python is not implemented like Java. In Java (at least in HotSpot),
the byte code is further compiled to machine code before
I'm pretty new to python, but am very happy with it. As well as using
it at work I've been using it to solve various puzzles on the Project
Euler site - http://projecteuler.net. So far it has not let me down,
but it has proved surprisingly slow on one puzzle.
The puzzle is: p is the perimeter of
On Sep 2, 12:51 pm, [EMAIL PROTECTED] wrote:
I'm pretty new to python, but am very happy with it. As well as using
it at work I've been using it to solve various puzzles on the Project
Euler site -http://projecteuler.net. So far it has not let me down,
but it has proved surprisingly slow on
On Sep 2, 7:20 am, Arnaud Delobelle [EMAIL PROTECTED] wrote:
On Sep 2, 12:51 pm, [EMAIL PROTECTED] wrote:
I'm pretty new to python, but am very happy with it. As well as using
it at work I've been using it to solve various puzzles on the Project
Euler site -http://projecteuler.net. So
[EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
The puzzle is: p is the perimeter of a right angle triangle with
integral length sides, {a,b,c}. which value of p 1000, is the
number of solutions {a,b,c} maximised?
Here's my python code:
#!/usr/local/bin/python
solutions = [0] *
[snip code]
Thanks for that. I realise that improving the algorithm will speed
things up. I wanted to know why my less than perfect algorithm was so
much slower in python than exactly the same algorithm in C. Even when
turning off gcc's optimiser with the -O0 flag, the C version is still
100
On Sep 2, 9:45 am, [EMAIL PROTECTED] wrote:
[snip code]
Thanks for that. I realise that improving the algorithm will speed
things up. I wanted to know why my less than perfect algorithm was so
much slower in python than exactly the same algorithm in C. Even when
turning off gcc's optimiser
On Sep 2, 9:45 pm, [EMAIL PROTECTED] wrote:
[snip code]
Thanks for that. I realise that improving the algorithm will speed
things up. I wanted to know why my less than perfect algorithm was so
much slower in python than exactly the same algorithm in C. Even when
turning off gcc's optimiser
On Sep 2, 12:51 pm, [EMAIL PROTECTED] wrote:
[...]
The resulting executable takes 0.24 seconds to run. I'm not expecting
a scripting language to run faster than native code, but I was
surprised at how much slower it was in this case. Any ideas as to what
is causing python so much trouble in
In article [EMAIL PROTECTED],
Mark Dickinson [EMAIL PROTECTED] wrote:
On Sep 2, 9:45 am, [EMAIL PROTECTED] wrote:
[snip code]
Thanks for that. I realise that improving the algorithm will speed
things up. I wanted to know why my less than perfect algorithm was so
much slower in python than
Ivan Wang a écrit :
On Sep 2, 9:45 pm, [EMAIL PROTECTED] wrote:
[snip code]
Thanks for that. I realise that improving the algorithm will speed
things up. I wanted to know why my less than perfect algorithm was so
much slower in python than exactly the same algorithm in C. Even when
turning off
Mark Dickinson [EMAIL PROTECTED] wrote:
On Sep 2, 9:45 am, [EMAIL PROTECTED] wrote:
[snip code]
Thanks for that. I realise that improving the algorithm will speed
things up. I wanted to know why my less than perfect algorithm was so
much slower in python than exactly the same algorithm
[EMAIL PROTECTED] (Alex Martelli) writes:
...which suggests that creating an xrange object is _cheaper_ than
indexing a list...
Why not re-use the xrange instead of keeping a list around?
Python 2.4.4 (#1, Oct 23 2006, 13:58:00)
a = xrange(3)
print list(a)
[0, 1, 2]
Paul Rubin http://[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Alex Martelli) writes:
...which suggests that creating an xrange object is _cheaper_ than
indexing a list...
Why not re-use the xrange instead of keeping a list around?
Python 2.4.4 (#1, Oct 23 2006, 13:58:00)
a =
[EMAIL PROTECTED] (Alex Martelli) writes:
Reusing xranges is exactly what my code was doing
Oh cool, I missed that, I was just going by the text description.
Looking at the code, yes, it's re-using the xranges. Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 2, 12:55 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
Mark Dickinson [EMAIL PROTECTED] wrote:
Well, for one thing, you're creating half a million xrange objects in
the course of the search. All the C code has
to do is increment a few integers.
I don't think the creation of xrange
(2) it is a interpretation language
Not quite. It's compiled to byte-code - just like Java (would you call
Java an 'interpreted language' ?)
Python is not implemented like Java. In Java (at least in HotSpot),
the byte code is further compiled to machine code before execution;
in Python, the
Mark Dickinson [EMAIL PROTECTED] wrote:
On Sep 2, 12:55 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
Mark Dickinson [EMAIL PROTECTED] wrote:
Well, for one thing, you're creating half a million xrange objects in
the course of the search. All the C code has
to do is increment a few
Martin v. Löwis wrote:
(2) it is a interpretation language
Not quite. It's compiled to byte-code - just like Java (would you call
Java an 'interpreted language' ?)
Python is not implemented like Java. In Java (at least in HotSpot),
the byte code is further compiled to machine code before
On Sep 2, 7:51 am, [EMAIL PROTECTED] wrote:
The resulting executable takes 0.24 seconds to run. I'm not expecting
a scripting language to run faster than native code, but I was
surprised at how much slower it was in this case. Any ideas as to what
is causing python so much trouble in the above
On Sun, 02 Sep 2007 21:00:45 +0200, Wildemar Wildenburger wrote:
Martin v. Löwis wrote:
(2) it is a interpretation language
Not quite. It's compiled to byte-code - just like Java (would you call
Java an 'interpreted language' ?)
Python is not implemented like Java. In Java (at least in
Wildemar Wildenburger schrieb:
Martin v. Löwis wrote:
(2) it is a interpretation language
Not quite. It's compiled to byte-code - just like Java (would you call
Java an 'interpreted language' ?)
Python is not implemented like Java. In Java (at least in HotSpot),
the byte code is further
On 9/2/07, Diez B. Roggisch [EMAIL PROTECTED] wrote:
Wildemar Wildenburger schrieb:
Martin v. Löwis wrote:
(2) it is a interpretation language
Not quite. It's compiled to byte-code - just like Java (would you call
Java an 'interpreted language' ?)
Python is not implemented like Java.
On 2007-09-02, Martin v. Löwis [EMAIL PROTECTED] wrote:
(2) it is a interpretation language
Not quite. It's compiled to byte-code - just like Java (would
you call Java an 'interpreted language' ?)
Python is not implemented like Java. In Java (at least in
HotSpot), the byte code is further
On 2007-09-02, Steven D'Aprano
[EMAIL PROTECTED] wrote:
A big question mark in my mind is Lisp, which according to
aficionados is just as dynamic as Python, but has native
compilers that generate code running as fast as highly
optimized C. I'm not qualified to judge whether the lessons
learnt
31 matches
Mail list logo
