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
24 matches
Mail list logo
