On 2018-09-18 17:05, ast wrote:
> Le 18/09/2018 à 17:01, ast a écrit :
>> Hello
>>
>> I found a smart and very concise code to
>> generate all permutations of a list.
>> I put it here if someone is interested to
>> figure out how it works
When you say "found a [...] code" I hope you mean "wrote a
Le 18/09/2018 à 17:01, ast a écrit :
error: permut instead of S
yield from permut(li2, prefix+[elt])
--
https://mail.python.org/mailman/listinfo/python-list
Hello
I found a smart and very concise code to
generate all permutations of a list.
I put it here if someone is interested to
figure out how it works
def permut(li, prefix=[]):
if len(li)==1:
yield prefix + li
else:
for elt in li:
li2 = li.copy()
Thank you so much, this all clear for me now
--
https://mail.python.org/mailman/listinfo/python-list
ne is just
performing an early exit from the iteration. You could write it
without any returns like this:
def fg(args):
if not args:
yield ""
else:
for i in args[0]:
for tmp in fg(args[1:]):
yield i + tmp
this is the Tower of Hanoi with recursive generator but i
Thanks for your detail explanation, my problem may be the 'return' keyword. I
confuse at the point that return come after yield keyword, I wonder what if in
case this code do not have the 1st return. So, when i try to delete the 1st
return, the code run with error (the list out of range).
This
On Tue, 1 Nov 2016 12:39 am, tpqnn...@gmail.com wrote:
> I have some confuse about the recursive generator where the code mixing
> Yield and return keywork as below. I understand that "return" keywork just
> raise StopIteration exception but can not understanding in depth, s
On Tue, Nov 1, 2016 at 1:50 AM, wrote:
>
> Please see the exampl I just got it below, this is the Tower of Hanoi with
> recursive generator but it do not have the 'return' here, do you have the
> advice for this term:
>
> def A001511():
> yield 1
&
Hi Chris,
Please see the exampl I just got it below, this is the Tower of Hanoi with
recursive generator but it do not have the 'return' here, do you have the
advice for this term:
def A001511():
yield 1
b=1
for x in A001511():
yield x+1
yield 1
tri
On Tue, Nov 1, 2016 at 1:03 AM, wrote:
> Hi ChrisA,
>
> Thank you so much for sharing this point, I just concern to the point that:
> normally, I found that the generator (it may be recursive generator also) do
> not apply the "return" keyword, just the yield only.
Hi ChrisA,
Thank you so much for sharing this point, I just concern to the point that:
normally, I found that the generator (it may be recursive generator also) do
not apply the "return" keyword, just the yield only. But when I delete one or
both of "return" keyword ab
On Tue, Nov 1, 2016 at 12:39 AM, wrote:
> I have some confuse about the recursive generator where the code mixing Yield
> and return keywork as below. I understand that "return" keywork just raise
> StopIteration exception but can not understanding in depth, so, could som
I have some confuse about the recursive generator where the code mixing Yield
and return keywork as below. I understand that "return" keywork just raise
StopIteration exception but can not understanding in depth, so, could some one
explain me about the actual function of two "r
On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan wrote:
>
> Short story: the subject says it all, so if you have an answer already,
> fire away. Below is the long story of what I'm using it for, and why I
> think it needs to be recursive. It may even be of more general
> interest in terms of filteri
On 27 November 2013 10:25, John O'Hagan wrote:
> On Tue, 26 Nov 2013 10:33:06 +
> Oscar Benjamin wrote:
>
> I simplified it a bit more to this:
>
> def word_sequences(prepend, target, subwords):
> """subwords is a list of lists of subwords grouped by length,
> in order of length""
On Tue, 26 Nov 2013 10:33:06 +
Oscar Benjamin wrote:
> On 26 November 2013 06:18, John O'Hagan
> wrote:
> >
[...]
> >
> > def _multicombs(prepend, words, r, chkstr):
> > """chkstr is the string of remaining availalable characters"""
> > if r == 0:
> > yield prepend, chkstr
>
On 26 November 2013 06:18, John O'Hagan wrote:
>
> Thanks, that is exactly the type of thing I was after. Although it is
> actually slower as is than a hack like
>
> def imulticombs(it, n):
> last = ()
> for i in itertools.combinations(it,n):
> if i > last:
> yield i
>
On Mon, 25 Nov 2013 12:15:15 +
Oscar Benjamin wrote:
> On 21 November 2013 13:01, John O'Hagan
> wrote:
> > In my use-case the first argument to multicombs is a tuple of words
> > which may contain duplicates, and it produces all unique
> > combinations of a certain length of those words, eg
On 21 November 2013 13:01, John O'Hagan wrote:
> In my use-case the first argument to multicombs is a tuple of words
> which may contain duplicates, and it produces all unique combinations
> of a certain length of those words, eg:
>
> list(multicombs(('cat', 'hat', 'in', 'the', 'the'), 3))
>
> [('
On Fri, 22 Nov 2013 22:33:29 -0800
Dan Stromberg wrote:
> On Fri, Nov 22, 2013 at 4:58 PM, John O'Hagan
> wrote:
>
> > On Thu, 21 Nov 2013 12:59:26 -0800
> > Dan Stromberg wrote:
> >
> > > On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
> > > wrote:
> > >
> > > >
> > > > Short story: the subject
On Sat, 23 Nov 2013 04:23:42 +
MRAB wrote:
> On 23/11/2013 00:58, John O'Hagan wrote:
> > On Thu, 21 Nov 2013 12:59:26 -0800
> > Dan Stromberg wrote:
> >
> >> On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
> >> wrote:
> >>
> >> >
> >> > Short story: the subject says it all, so if you have an
On Fri, Nov 22, 2013 at 4:58 PM, John O'Hagan wrote:
> On Thu, 21 Nov 2013 12:59:26 -0800
> Dan Stromberg wrote:
>
> > On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
> > wrote:
> >
> > >
> > > Short story: the subject says it all, so if you have an answer
> > > already, fire away. Below is the lo
On 23/11/2013 00:58, John O'Hagan wrote:
On Thu, 21 Nov 2013 12:59:26 -0800
Dan Stromberg wrote:
On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
wrote:
>
> Short story: the subject says it all, so if you have an answer
> already, fire away. Below is the long story of what I'm using it
> for, a
On Thu, 21 Nov 2013 18:14:41 -0800 (PST)
James wrote:
> On Thursday, November 21, 2013 5:01:15 AM UTC-8, John O'Hagan wrote:
[...]
> > > On 21 November 2013 06:46, John O'Hagan
> >
> > > wrote:
> >
[...]
> >
> > > > def multicombs(it, r):
> >
> > > > result = it[:r]
> >
> > > >
On Thu, 21 Nov 2013 12:59:26 -0800
Dan Stromberg wrote:
> On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
> wrote:
>
> >
> > Short story: the subject says it all, so if you have an answer
> > already, fire away. Below is the long story of what I'm using it
> > for, and why I think it needs to be
On Thursday, November 21, 2013 5:01:15 AM UTC-8, John O'Hagan wrote:
> On Thu, 21 Nov 2013 11:42:49 +
>
> Oscar Benjamin wrote:
>
>
>
> > On 21 November 2013 06:46, John O'Hagan
>
> > wrote:
>
> > >
>
> > > I found a verbal description of such an algorithm and came up with
>
> > > thi
On Thu, 21 Nov 2013 11:42:49 +
Oscar Benjamin wrote:
> On 21 November 2013 06:46, John O'Hagan
> wrote:
> >
> > I found a verbal description of such an algorithm and came up with
> > this:
> >
> > def multicombs(it, r):
> > result = it[:r]
> > yield result
> > while 1:
> >
On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan wrote:
>
> Short story: the subject says it all, so if you have an answer already,
> fire away. Below is the long story of what I'm using it for, and why I
> think it needs to be recursive. It may even be of more general
> interest in terms of filteri
On 21 November 2013 06:46, John O'Hagan wrote:
>
> I found a verbal description of such an algorithm and came up with
> this:
>
> def multicombs(it, r):
> result = it[:r]
> yield result
> while 1:
> for i in range(-1, -r - 1, -1):
> rep = result[i]
> if
e for medium-length inputs, much more
for longer strings) by replacing itertools.product with this recursive
generator:
def cartesian_product(args, input_str):
if not args:
yield (), input_str
return
for words, check_str in cartesian_product(args[:-1], input_str):
On Sun, 21 Oct 2012 17:40:41 -0700, David wrote:
> If I have one "yield" in function, the function will become generator,
Almost correct. The function becomes a *generator function*, that is, a
function that returns a generator object.
Sometimes people abbreviate that to "generator", but that i
On Monday, October 22, 2012 7:59:53 AM UTC+8, Terry Reedy wrote:
> On 10/21/2012 7:29 PM, David wrote:
>
> > I have a tree-like data structure, the basic elements are hash tables,
>
> > and they are grouped into lists, like [[{'a':1},[{'b':2}]]].
>
> > And I want to flat the lists and visit hash
On 10/21/2012 7:29 PM, David wrote:
I have a tree-like data structure, the basic elements are hash tables,
and they are grouped into lists, like [[{'a':1},[{'b':2}]]].
And I want to flat the lists and visit hash table one by one, like {'a':1},
{'b':2}.
But my program didn't work as I wish. When
I have a tree-like data structure, the basic elements are hash tables,
and they are grouped into lists, like [[{'a':1},[{'b':2}]]].
And I want to flat the lists and visit hash table one by one, like {'a':1},
{'b':2}.
But my program didn't work as I wish. When it entered the 2nd
flat_yield, it thre
I don't know how many times I stared at that code without seeing the error.
Thanks so much!
Phillip
On Fri, Sep 23, 2011 at 1:26 PM, Arnaud Delobelle wrote:
> On 23 September 2011 21:09, Dr. Phillip M. Feldman
> wrote:
> >
> > A few weeks ago, I wrote a class that creates an iterator for solv
On 23 September 2011 21:09, Dr. Phillip M. Feldman
wrote:
>
> A few weeks ago, I wrote a class that creates an iterator for solving the
> general unlabeled-balls-in-labeled boxes occupancy problem. Chris Rebert
> converted my code to a generator, which made the code cleaner, and I
> subsequently s
above, but one of
them is now missing. If someone can shed light on why this is happening, I'd
be grateful.
Phillip
http://old.nabble.com/file/p32503886/balls_in_labeled_boxes.py
balls_in_labeled_boxes.py
--
View this message in context:
http://old.nabble.com/strange-behavior-from-recursive
On 2008-02-13, Erich <[EMAIL PROTECTED]> wrote:
> On Feb 12, 5:15 am, Ben C <[EMAIL PROTECTED]> wrote:
>> I think this works OK, but it seems a bit odd. Is there something more
>> "Pythonic" I should be doing?
>
> I have a similar tree to the one you describe here at work. I have a
> visit function
On Feb 12, 5:15 am, Ben C <[EMAIL PROTECTED]> wrote:
> I think this works OK, but it seems a bit odd. Is there something more
> "Pythonic" I should be doing?
I have a similar tree to the one you describe here at work. I have a
visit function that is very similar to yours, but takes function
argume
On 2008-02-12, Paul Hankin <[EMAIL PROTECTED]> wrote:
> On Feb 12, 10:17 pm, Ben C <[EMAIL PROTECTED]> wrote:
>> On 2008-02-12, Paul Rubin <> wrote:
>>
>> > Paul Hankin <[EMAIL PROTECTED]> writes:
>> >> def genDescendants(self):
>> >> return chain([self], *[child.genDescendants()
>> >>
On Feb 12, 10:17 pm, Ben C <[EMAIL PROTECTED]> wrote:
> On 2008-02-12, Paul Rubin <> wrote:
>
> > Paul Hankin <[EMAIL PROTECTED]> writes:
> >> def genDescendants(self):
> >> return chain([self], *[child.genDescendants()
> >> for child in self.children])
>
> > That is scary. It generate
On 2008-02-12, Paul Rubin <> wrote:
> Paul Hankin <[EMAIL PROTECTED]> writes:
>> def genDescendants(self):
>> return chain([self], *[child.genDescendants()
>> for child in self.children])
>
> That is scary. It generates an in-memory list the size of the
> whole subtree, at every level.
Paul Hankin <[EMAIL PROTECTED]> writes:
> def genDescendants(self):
> return chain([self], *[child.genDescendants()
> for child in self.children])
That is scary. It generates an in-memory list the size of the
whole subtree, at every level. Total memory consumption is maybe
even quadr
On 2008-02-12, Paul Hankin <[EMAIL PROTECTED]> wrote:
> On Feb 12, 11:15 am, Ben C <[EMAIL PROTECTED]> wrote:
>> Suppose I have an object containing an array called children. I can
>> therefore build a tree out of such objects.
>> The best I came up with so far is :
>>
>> def genDescendents(sel
On Feb 12, 11:15 am, Ben C <[EMAIL PROTECTED]> wrote:
> Suppose I have an object containing an array called children. I can
> therefore build a tree out of such objects.
> The best I came up with so far is :
>
> def genDescendents(self):
> for child in self.children:
> yield
Suppose I have an object containing an array called children. I can
therefore build a tree out of such objects.
I thought it might be useful to have a descendent generator, so I could
write:
for thing in self.genDescendents():
foo(thing)
expecting foo to be called for each descendent
aurora wrote:
> This test somehow water down the n^2 issue. The problem is in the depth
> of recursion, in this case it is only log(n). It is probably more
> interesting to test:
>
> def gen(n):
> if n:
> yield n
> for i in gen(n-1):
> yield i
You should be
> You seem to be assuming that a yield statement and a function call are
> equivalent. I'm not sure that's a valid assumption.
I don't know. I was hoping the compiler can optimize away the chain of
yields.
> Anyway, here's some data to consider:
>
> test.py -
On Thu, 11 Aug 2005 01:18:11 -0700, Matt Hammond
<[EMAIL PROTECTED]> wrote:
>
>> Is it an inherent issue in the use of recursive generator? Is there any
>> compiler optimization possible?
>
> Hi, I could be misunderstanding it myself, but I think the short answer
aurora wrote:
> I love generator and I use it a lot. Lately I've been writing some
> recursive generator to traverse tree structures. After taking closer
> look I have some concern on its performance.
>
> Let's take the inorder traversal from
> http://www.python.
"aurora" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I love generator and I use it a lot. Lately I've been writing some
> recursive generator to traverse tree structures. After taking closer look
> I have some concern on its performance.
Wh
t issue in the use of recursive generator? Is there
> any compiler optimization possible?
>
Do you actually have timing evidence that this is a problem with the data
you are processing? The complexity of the algorithm may be important for
very large data sets, but until you time it you won&#
> Is it an inherent issue in the use of recursive generator? Is there any
> compiler optimization possible?
Hi, I could be misunderstanding it myself, but I think the short answer to
your question is that its an inherent limitation.
> def inorder(t):
> if t:
> f
I love generator and I use it a lot. Lately I've been writing some
recursive generator to traverse tree structures. After taking closer look
I have some concern on its performance.
Let's take the inorder traversal from
http://www.python.org/peps/pep-0255.html as an example.
def
54 matches
Mail list logo
