Duncan Booth duncan.bo...@invalid.invalid writes:
Duncan Booth duncan.bo...@invalid.invalid wrote:
John Posner jjpos...@snet.net wrote:
Do know what in the itertools implementation causes adding a 'if p =
sqrt(n)' clause to *decrease* performance, while adding a
'takewhile()' clause
On Apr 13, 1:39 am, Arnaud Delobelle arno...@googlemail.com wrote:
Duncan Booth duncan.bo...@invalid.invalid writes:
Duncan Booth duncan.bo...@invalid.invalid wrote:
John Posner jjpos...@snet.net wrote:
Do know what in the itertools implementation causes adding a 'if p =
sqrt(n)' clause
John Posner jjpos...@snet.net wrote:
Do know what in the itertools implementation causes adding a 'if p =
sqrt(n)' clause to *decrease* performance, while adding a
'takewhile()' clause *increases* performance?
I haven't timed it, but I would guess that the takewhile was faster
only because
Duncan Booth duncan.bo...@invalid.invalid writes:
John Posner jjpos...@snet.net wrote:
Do know what in the itertools implementation causes adding a 'if p =
sqrt(n)' clause to *decrease* performance, while adding a
'takewhile()' clause *increases* performance?
I haven't timed it, but I
Duncan Booth wrote:
John Posner jjpos...@snet.net wrote:
Do know what in the itertools implementation causes adding a 'if p =
sqrt(n)' clause to *decrease* performance, while adding a
'takewhile()' clause *increases* performance?
I haven't timed it, but I would guess that the
Duncan Booth duncan.bo...@invalid.invalid wrote:
John Posner jjpos...@snet.net wrote:
Do know what in the itertools implementation causes adding a 'if p =
sqrt(n)' clause to *decrease* performance, while adding a
'takewhile()' clause *increases* performance?
I haven't timed it, but I
John Posner jjpos...@snet.net writes:
Inspired by recent threads (and recalling my first message to Python
edu-sig), I did some Internet searching on producing prime numbers using
Python generators. Most algorithms I found don't go for the infinite,
contenting themselves with list all the
Arnaud Delobelle wrote:
You could do something like this with the help of itertools.ifilter:
prime_gen = ifilter(
lambda n, P=[]: all(n%p for p in P) and not P.append(n),
count(2)
)
Formidable! (both the English and French meanings) This is the most
elegant, Sieve of
On Sun, 05 Apr 2009 00:28:17 -0400, Miles wrote:
def prime_gen():
primes = []
return (primes.append(n) or n for n in count(2) if all(n%p for p
in primes if p=sqrt(n)))
That version is only marginally faster than your original version. The
biggest performance penalty is that the
Kay Schluehr said:
g = (lambda primes = []:
(n for n in count(2) \
if
(lambda n, primes: (n in primes if primes and
n=primes[-1] \
else
(primes.append(n) or True \
if all(n%p for p in primes if p = sqrt(n)) \
On 5 Apr., 17:14, John Posner jjpos...@snet.net wrote:
Kay Schluehr said:
g = (lambda primes = []:
(n for n in count(2) \
if
(lambda n, primes: (n in primes if primes and
n=primes[-1] \
else
(primes.append(n) or True \
:37 AM
To: python-list@python.org
Subject: Re: Generators/iterators, Pythonicity, and primes
On 5 Apr., 17:14, John Posner jjpos...@snet.net wrote:
Kay Schluehr said:
g = (lambda primes = []:
(n for n in count(2) \
if
(lambda n, primes: (n in primes if primes
Kay Schluehr wrote:
That's because it is *one* expression. The avoidance of named
functions makes it look obfuscated or prodigious. Once it is properly
dissected it doesn't look that amazing anymore.
Start with:
(n for n in count(2) if is_prime(n, primes))
The is_prime function has
On 5 Apr., 18:47, John Posner jjpos...@snet.net wrote:
Kay Schluehr wrote:
That's because it is *one* expression. The avoidance of named
functions makes it look obfuscated or prodigious. Once it is properly
dissected it doesn't look that amazing anymore.
Start with:
(n for n
g = (lambda primes = []:
(n for n in count(2) if
(lambda x, primes:
(primes.append(x) or True
if all(x%p for p in primes if p = sqrt(x))
else False)
)(n, primes)
)
)()
This is
Steven D'Aprano wrote:
On Sun, 05 Apr 2009 00:28:17 -0400, Miles wrote:
def prime_gen(): ...
That's pretty sweet, but we can make it even faster. We can speed things
up by incrementing by two instead of one, to avoid pointlessly testing
even numbers that we know must fail. We can also speed
Inspired by recent threads (and recalling my first message to Python
edu-sig), I did some Internet searching on producing prime numbers using
Python generators. Most algorithms I found don't go for the infinite,
contenting themselves with list all the primes below a given number.
Here's a very
John Posner jjpos...@snet.net wrote in message
news:af9fbcc3a7624599a6f51bad2397e...@amdup...
Inspired by recent threads (and recalling my first message to Python
edu-sig), I did some Internet searching on producing prime numbers using
Python generators. Most algorithms I found don't go for
Mark Tolonen said:
p = sqrt(n) works a little better :^)
-Mark
Right you are -- I found that bug in my last-minute check, and then I forgot
to trannscribe the fix into the email message. Duh -- thanks!
-John
E-mail message checked by Spyware Doctor (6.0.0.386)
Database version:
John Posner wrote:
Inspired by recent threads (and recalling my first message to Python
edu-sig), I did some Internet searching on producing prime numbers using
Python generators. Most algorithms I found don't go for the infinite,
contenting themselves with list all the primes below a given
On Sat, Apr 4, 2009 at 2:50 PM, John Posner wrote:
Inspired by recent threads (and recalling my first message to Python
edu-sig), I did some Internet searching on producing prime numbers using
Python generators. Most algorithms I found don't go for the infinite,
contenting themselves with list
Question: Is there a way to implement this algorithm using generator
expressions only -- no yield statements allowed?
Yes. Avoiding the yield statement is easy but one might eventually end
up with two statements because one has to produce a side effect on the
primes list. However we can use
22 matches
Mail list logo
