On Apr 13, 1:39 am, Arnaud Delobelle wrote:
> Duncan Booth writes:
> > Duncan Booth wrote:
>
> >> John Posner wrote:
>
> >>> Do know what in the itertools implementation causes adding a 'if p <=
> >>> sqrt(n)' clause to *decrease* performance, while adding a
> >>> 'takewhile()' clause *increase
Duncan Booth writes:
> Duncan Booth wrote:
>
>> John Posner 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 woul
Duncan Booth wrote:
> John Posner 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 fa
Duncan Booth wrote:
John Posner 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
on
Duncan Booth writes:
> John Posner 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 fas
John Posner 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 the sqrt(n) ha
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 Eratos
John Posner 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 primes below a g
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 th
>> > 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)
>> >
On 5 Apr., 18:47, John Posner 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 i
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
009 8:37 AM
To: python-list@python.org
Subject: Re: Generators/iterators, Pythonicity, and primes
On 5 Apr., 17:14, John Posner wrote:
> Kay Schluehr said:
>
> > g = (lambda primes = []:
> > (n for n in count(2) \
> > if
> > (lambda n,
On 5 Apr., 17:14, John Posner 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 \
> >
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 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
> 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
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 "
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 numb
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
"John Posner" 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 the infinite,
cont
21 matches
Mail list logo
