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


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

Re: Fast recursive generators?

Started byTerry Reedy <tjreedy@udel.edu>
First post2011-10-28 22:27 -0400
Last post2011-10-28 22:27 -0400
Articles 1 — 1 participant

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: Fast recursive generators? Terry Reedy <tjreedy@udel.edu> - 2011-10-28 22:27 -0400

#15127 — Re: Fast recursive generators?

FromTerry Reedy <tjreedy@udel.edu>
Date2011-10-28 22:27 -0400
SubjectRe: Fast recursive generators?
Message-ID<mailman.2299.1319855279.27778.python-list@python.org>
On 10/28/2011 8:49 PM, Michael McGlothlin wrote:

>> Better to think of a sequence of values, whether materialized as a 'list' or
>> not.
>
> The final value will actually be a string but it seems it is usually
> faster to join a list of strings than to concat them one by one.

.join() takes an iterable of strings as its argument

>> Comprehensions combine map and filter, both of which conceptually work on
>> each item of a pre-existing list independently. (I am aware that the
>> function passed can stash away values to create dependence.
>
> The problem is I don't really have a pre-existing list.

So, as I said, map, filter, and comprehensions are not applicable to 
your problem.

>> def do(func, N, value):
>>     yield value
>>     for i in range(1,N):
>>         value = func(value)
>>         yield value
>>
>> For more generality, make func a function of both value and i.
>> If you need a list, "l = list(do(f,N,x))", but if you do not, you can do
>> "for item in do(f,N,x):" and skip making the list.
>
> Generators seem considerably slower than using comprehension or
> map/filter

So what? A saw may cut faster than a hammer builds, but I hope you don't 
grab a saw when you need a hammer.

 > /reduce.

Do you actually have an example where ''.join(reduce(update, N, start)) 
is faster than ''.join(update_gen(N, start))? Resuming a generator n 
times should be *faster* than n calls to the update function of reduce 
(which will actually have to build a list).

---
Terry Jan Reedy

[toc] | [standalone]


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


csiph-web