Le vendredi 28 Janvier 2005 08:27, Paul Rubin a écrit :
> Francis Girard <[EMAIL PROTECTED]> writes:
> > Thank you Nick and Steven for the idea of a more generic imerge.
>
> If you want to get fancy, the merge should use a priority queue (like
> in the heapsort algorithm) instead of a linear scan t
Paul Rubin wrote:
Francis Girard <[EMAIL PROTECTED]> writes:
Thank you Nick and Steven for the idea of a more generic imerge.
If you want to get fancy, the merge should use a priority queue (like
in the heapsort algorithm) instead of a linear scan through the
incoming iters, to find the next item
Francis Girard <[EMAIL PROTECTED]> writes:
> Thank you Nick and Steven for the idea of a more generic imerge.
If you want to get fancy, the merge should use a priority queue (like
in the heapsort algorithm) instead of a linear scan through the
incoming iters, to find the next item to output. That
Le jeudi 27 Janvier 2005 10:30, Nick Craig-Wood a ÃcritÂ:
> Francis Girard <[EMAIL PROTECTED]> wrote:
> > Thank you Nick and Steven for the idea of a more generic imerge.
>
> You are welcome :-) [It came to me while walking the children to school!]
>
Sometimes fresh air and children purity is al
Francis Girard <[EMAIL PROTECTED]> wrote:
> Thank you Nick and Steven for the idea of a more generic imerge.
You are welcome :-) [It came to me while walking the children to school!]
[snip]
> class IteratorDeiterator:
>def __init__(self, iterator):
> self._iterator = iterator.__iter__
Francis Girard wrote:
For the imerge function, what we really need to make the formulation clear is
a way to look at the next element of an iteratable without consuming it. Or
else, a way to put back "consumed" elements in the front an iteration flow,
much like the list constructors in FP langua
Le mardi 25 Janvier 2005 19:52, Steven Bethard a écrit :
Thank you Nick and Steven for the idea of a more generic imerge.
To work with the Hamming problem, the imerge function _must_not_ allow
duplicates and we can assume all of the specified iteratables are of the same
size, i.e. infinite !
T
Le mardi 25 Janvier 2005 09:01, Michael Spencer a ÃcritÂ:
> Francis Girard wrote:
> > The following implementation is even more speaking as it makes
> > self-evident and almost mechanical how to translate algorithms that run
> > after their tail from recursion to "tee" usage :
>
> Thanks, Francis a
On Tue, 25 Jan 2005 11:46:04 -0800, Jeff Shannon <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>
>> On 25 Jan 2005 08:30:03 GMT, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
>>
>>>If you are after readability, you might prefer this...
>>>
>>>def hamming():
>>> def _hamming():
>>> yield 1
>>>
Bengt Richter wrote:
On 25 Jan 2005 08:30:03 GMT, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
If you are after readability, you might prefer this...
def hamming():
def _hamming():
yield 1
for n in imerge(imap(lambda h: 2*h, iter(hamming2)),
imerge(imap(lambda h: 3*h, iter(hammi
Nick Craig-Wood wrote:
Steven Bethard <[EMAIL PROTECTED]> wrote:
Nick Craig-Wood wrote:
Thinking about this some more leads me to believe a general purpose
imerge taking any number of arguments will look neater, eg
def imerge(*generators):
values = [ g.next() for g in generators ]
while True:
Nick Craig-Wood wrote:
Steven Bethard <[EMAIL PROTECTED]> wrote:
Nick Craig-Wood wrote:
Thinking about this some more leads me to believe a general purpose
imerge taking any number of arguments will look neater, eg
def imerge(*generators):
values = [ g.next() for g in generators ]
while True:
Steven Bethard <[EMAIL PROTECTED]> wrote:
> Nick Craig-Wood wrote:
> > Thinking about this some more leads me to believe a general purpose
> > imerge taking any number of arguments will look neater, eg
> >
> > def imerge(*generators):
> > values = [ g.next() for g in generators ]
> > whil
Nick Craig-Wood wrote:
Thinking about this some more leads me to believe a general purpose
imerge taking any number of arguments will look neater, eg
def imerge(*generators):
values = [ g.next() for g in generators ]
while True:
x = min(values)
yield x
for i in range
Francis Girard <[EMAIL PROTECTED]> wrote:
> The following implementation is even more speaking as it makes self-evident
> and almost mechanical how to translate algorithms that run after their tail
> from recursion to "tee" usage :
>
> *** BEGIN SNAP
> from itertools import tee, imap
> imp
On 25 Jan 2005 08:30:03 GMT, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
>Francis Girard <[EMAIL PROTECTED]> wrote:
>> def hamming():
>>def _hamming():
>> yield 1
>> hamming2 = hammingGenerators[0]
>> hamming3 = hammingGenerators[1]
>> hamming5 = hammingGenerators[2]
>>
Francis Girard <[EMAIL PROTECTED]> wrote:
> def hamming():
>def _hamming():
> yield 1
> hamming2 = hammingGenerators[0]
> hamming3 = hammingGenerators[1]
> hamming5 = hammingGenerators[2]
> for n in imerge(imap(lambda h: 2*h, iter(hamming2)),
> ime
Francis Girard wrote:
The following implementation is even more speaking as it makes self-evident
and almost mechanical how to translate algorithms that run after their tail
from recursion to "tee" usage :
Thanks, Francis and Jeff for raising a fascinating topic. I've enjoyed trying
to get my
Ok I'll submit the patch with the prose pretty soon.
Thank you
Francis Girard
FRANCE
Le mardi 25 Janvier 2005 04:29, Tim Peters a écrit :
> [Francis Girard]
>
> > For all the algorithms that run after their tail in an FP way, like the
> > Hamming problem, or the Fibonacci sequence, (but unlike Sie
[Francis Girard]
> For all the algorithms that run after their tail in an FP way, like the
> Hamming problem, or the Fibonacci sequence, (but unlike Sieve of Eratosthene
> -- there's a subtle difference), i.e. all those algorithms that typically
> rely upon recursion to get the beginning of the gen
The following implementation is even more speaking as it makes self-evident
and almost mechanical how to translate algorithms that run after their tail
from recursion to "tee" usage :
*** BEGIN SNAP
from itertools import tee, imap
import sys
def imerge(xs, ys):
x = xs.next()
y = ys.next()
Ok, I think that the bottom line is this :
For all the algorithms that run after their tail in an FP way, like the
Hamming problem, or the Fibonacci sequence, (but unlike Sieve of Eratosthene
-- there's a subtle difference), i.e. all those algorithms that typically
rely upon recursion to get th
[Francis Girard]
> ...
> In the meantime, I couldn't resist to test the new Python features about
> laziness on a classical FP problem, i.e. the "Hamming" problem.
...
> Nevertheless, while the Haskell version prints Hamming sequence for as long as
> I can stand it, and with very little memory cons
Your formulation in Python is recursive (hamming calls hamming()) and I
think that's why your program gives up fairly early.
Instead, use itertools.tee() [new in Python 2.4, or search the internet
for an implementation that works in 2.3] to give a copy of the output
sequence to each "multiply by N
Hi,
First,
My deepest thanks to Craig Ringer, Alex Martelli, Nick Coghlan and Terry Reedy
for having generously answered on the "Need help on need help on generator"
thread. I'm compiling the answers to sketch myself a global pictures about
iterators, generators, iterator-generators and lazine
25 matches
Mail list logo
