Unyeilding a permutation generator

[sillyhat]

Hello, can someone please help.

I found the following code at http://code.activestate.com/recipes/252178/

def all_perms(str):
if len(str) <=1:
yield str
else:
for perm in all_perms(str[1:]):
for i in range(len(perm)+1):
#nb str[0:1] works in both string and list contexts
yield perm[:i] + str[0:1] + perm[i:]

which allows me to do things like

for x in all_permx("ABCD"):
print x

I believe it is making use of the plain changes / Johnson Trotter
algorithm.
Can someone please confirm?

Anyway what I want to do is experiment with code similar to this (i.e.
same algorithm and keep the recursion) in other languages,
particularly vbscript and wondered what it would look like if it was
rewritten to NOT use the yield statement - or at least if it was
amended so that it can be easily translated to other languages that
dont have python's yield statement. I think the statement "for perm in
all_perms(str[1:]):" will be hardest to replicate in a recursive
vbscript program for example.

Thanks for any constructive help given.

Hal

 

[Paul Rubin]

Anyway what I want to do is experiment with code similar to this (i.e.
same algorithm and keep the recursion) in other languages,
particularly vbscript and wondered what it would look like if it was
rewritten to NOT use the yield statement -

Without the yield statement and keeping the same space complexity, you
basically have to wrap the enumeration state in a data object that you
can enumerate over explicitly. That in turn may mean you have to
unwind the recursion into old fashioned stack operations.

 

[Carsten Haese]

Anyway what I want to do is experiment with code similar to this (i.e.
same algorithm and keep the recursion) in other languages,
particularly vbscript and wondered what it would look like if it was
rewritten to NOT use the yield statement

An obvious (though memory-inefficient) replacement is to accumulate a
list and return the list. Initialize a result variable to an empty list,
and instead of yielding elements, append them to the result variable.
Then return the result variable at the end of the function.

HTH,

 

[Aaron Brady]

Hello, can someone please help.

I found the following code athttp://code.activestate.com/recipes/252178/

def all_perms(str):
    if len(str) <=1:
        yield str
    else:
        for perm in all_perms(str[1:]):
            for i in range(len(perm)+1):
                #nb str[0:1] works in both string and list contexts
                yield perm[:i] + str[0:1] + perm[i:]

which allows me to do things like

for x in  all_permx("ABCD"):
  print x

I believe it is making use of the plain changes / Johnson Trotter
algorithm.
Can someone please confirm?

Anyway what I want to do is experiment with code similar to this (i.e.
same algorithm and keep the recursion) in other languages,
particularly vbscript and wondered what it would look like if it was
rewritten to NOT use the yield statement - or at least if it was
amended so that it can be easily translated to other languages that
dont have python's yield statement. I think the statement "for perm in
all_perms(str[1:]):"  will be hardest to replicate in a recursive
vbscript program for example.

Thanks for any constructive help given.

Hal

I think multi-threading is the "truest" to the original. You might
develop a framework to set events when particular generators are to
take a turn, place their "yields", per se, in a particular place, set
the return event, etc., and reuse it. Of course, starting threads in
VBS might be another matter.

 

[Steve Holden]

Hello, can someone please help.

I found the following code at http://code.activestate.com/recipes/252178/

def all_perms(str):
if len(str) <=1:
yield str
else:
for perm in all_perms(str[1:]):
for i in range(len(perm)+1):
#nb str[0:1] works in both string and list contexts
yield perm[:i] + str[0:1] + perm[i:]

which allows me to do things like

for x in all_permx("ABCD"):
print x

I believe it is making use of the plain changes / Johnson Trotter
algorithm.
Can someone please confirm?

Anyway what I want to do is experiment with code similar to this (i.e.
same algorithm and keep the recursion) in other languages,
particularly vbscript and wondered what it would look like if it was
rewritten to NOT use the yield statement - or at least if it was
amended so that it can be easily translated to other languages that
dont have python's yield statement. I think the statement "for perm in
all_perms(str[1:]):" will be hardest to replicate in a recursive
vbscript program for example.

There are various approaches you could use, the simplest of which is to
provide a "callback function" as an additional argument to the all_perms
function, and call it with the permutation as an argument in place of
the yield statement.

regards
Steve

 

[Terry Reedy]

(e-mail address removed) wrote:

Anyway what I want to do is experiment with code similar to this (i.e.
same algorithm and keep the recursion) in other languages,
particularly vbscript and wondered what it would look like if it was
rewritten to NOT use the yield statement - or at least if it was
amended so that it can be easily translated to other languages that
dont have python's yield statement. I think the statement "for perm in
all_perms(str[1:]):" will be hardest to replicate in a recursive
vbscript program for example.

There are various approaches you could use, the simplest of which is to
provide a "callback function" as an additional argument to the all_perms
function, and call it with the permutation as an argument in place of
the yield statement.

I had thought of three ways to avoid yield, that makes a fourth.

Summary:

1. Think of generator function as an abbreviated iterator class and
unabbreviate by writing a full iterator class with .__next__ (3.0).
+ Transparent to caller
- Will often have to re-arrange code a bit to save locals values as
attributes before returning. If there is an inner loop, efficiency may
require copying attributes to locals.

2. Add to collection rather than yield, then return collection rather
than raise StopIteration.
+ Transparent to caller; small change to function.
- Returned collection can be arbitrarily large and take an arbitrarily
long time to collect.

3. Add callback parameter and change 'yield value' to 'callback(value)'.
+ Minor change to generator function.
- Minor to major change to caller to turn consumer code into a callback
that somehow gets result of callback to where it is needed. (Avoiding
the major changes sometimes needed was one of the motivations for
generators.)

4. Combine caller and generator code by inlining one into or around the
other.
+ Neither code will change much.
- Loss benefit of modularity and reuse without cut-and-paste, which is
subject to error.

I have not thought through yet how well each of these work with
recursive generators.

Conclusion:

Generators with yield make Python a great language for expressing
combinatorial algorithms.

Terry Jan Reedy

 

[Michele Simionato]

Anyway what I want to do is experiment with code similar to this (i.e.
same algorithm and keep the recursion) in other languages,
particularly vbscript and wondered what it would look like if it was
rewritten to NOT use the yield statement - or at least if it was
amended so that it can be easily translated to other languages that
dont have python's yield statement. I think the statement "for perm in
all_perms(str[1:]):"  will be hardest to replicate in a recursive
vbscript program for example.

Thanks for any constructive help given.

Here is a solution which does not use yield, translittered
from some Scheme code I have:

def perm(lst):
ll = len(lst)
if ll == 0:
return []
elif ll == 1:
return [lst]
else:
return [[el] + ls for el in lst
for ls in perm([e for e in lst if not e==el])]

if __name__ == '__main__':
print perm('abcd')

 

[Jorgen Grahn]

On Nov 2, 3:34 pm, (e-mail address removed) wrote: .... ....
I think multi-threading is the "truest" to the original. You might
develop a framework to set events when particular generators are to
take a turn, place their "yields", per se, in a particular place, set
the return event, etc., and reuse it. Of course, starting threads in
VBS might be another matter.

Why multi-threading? I see no concurrency in the original algorithm.
There is, in my mind, nothing concurrent about 'yield'.

/Jorgen

 

[Marc 'BlackJack' Rintsch]

Why multi-threading? I see no concurrency in the original algorithm.
There is, in my mind, nothing concurrent about 'yield'.

No "real" concurrency but a generator can be seen as independent thread
of code where the generator code is allowed to run when `next()` is
called and stops itself when it ``yield``\s an object. Sort of
cooperative multitasking. The name "yield" is often used in concurrent
code like Java's or Io's `yield()` methods.

Ciao,
Marc 'BlackJack' Rintsch

 

[Aaron Brady]

No "real" concurrency but a generator can be seen as independent thread
of code where the generator code is allowed to run when `next()` is
called and stops itself when it ``yield``\s an object.  Sort of
cooperative multitasking.  The name "yield" is often used in concurrent
code like Java's or Io's `yield()` methods.

Ciao,
        Marc 'BlackJack' Rintsch

Further, it resumes where it left off when it gets control again:

"execution is stopped at the yield keyword (returning the result) and
is resumed there when the next element is requested by calling the
next() method" --the fine manual

It maintains and operates in its own separate execution frame, etc.

 

[sillyhat]

Anyway what I want to do is experiment with code similar to this (i.e.
same algorithm and keep the recursion) in other languages,
particularly vbscript and wondered what it would look like if it was
rewritten to NOT use the yield statement - or at least if it was
amended so that it can be easily translated to other languages that
dont have python's yield statement. I think the statement "for perm in
all_perms(str[1:]):"  will be hardest to replicate in a recursive
vbscript program for example.

Thanks for any constructive help given.

Here is a solution which does not use yield, translittered
from some Scheme code I have:

def perm(lst):
    ll = len(lst)
    if ll == 0:
        return []
    elif ll == 1:
        return [lst]
    else:
        return [[el] + ls for el in lst
                for ls in perm([e for e in lst if not e==el])]

if __name__ == '__main__':
    print perm('abcd')

Thats interesting code but seems to give a different output,
suggesting thet the underlying algorithm is different.
Ignoring linebreaks and case, the original code gives:
abcd bacd bcad bcda acbd cabd cbad cbda acdb cadb cdab cdba abdc badc
bdac bdca adbc dabc dbac dbca adcb dacb dcab dcba

The output from the above program, when converted to strings is:
abcd abdc acbd acdb adbc adcb bacd badc bcad bcda bdac bdca cabd cadb
cbad cbda cdab cdba dabc dacb dbac dbca dcab dcba

Cheers, Hal.

 

[sillyhat]

An obvious (though memory-inefficient) replacement is to accumulate a
list and return the list. Initialize a result variable to an empty list,
and instead of yielding elements, append them to the result variable.
Then return the result variable at the end of the function.

HTH,

That did it and I can still understand it!

def allperm(str):
if len(str) <= 1:
return str
else:
biglist = []
for perm in allperm(str[1:]):
for i in xrange(len(str)): #minor change here
biglist.append(perm[:i] + str[0:1] + perm[i:])

return biglist

for x in allperm("ABCD"):
print x

 

[Arnaud Delobelle]

Thats interesting code but seems to give a different output,
suggesting thet the underlying algorithm is different.

Yes.

Yours takes the first element out of the list and inserts it in every
position of all the permutations of the list without the first element:

Ignoring linebreaks and case, the original code gives:
abcd bacd bcad bcda acbd cabd cbad cbda acdb cadb cdab cdba abdc badc
bdac bdca adbc dabc dbac dbca adcb dacb dcab dcba

Michele's takes every element out of the list in turn and appends every
permutation of the list without this element to its right:

 

[Gerard Flanagan]

Thats interesting code but seems to give a different output,
suggesting thet the underlying algorithm is different.
Ignoring linebreaks and case, the original code gives:
abcd bacd bcad bcda acbd cabd cbad cbda acdb cadb cdab cdba abdc badc
bdac bdca adbc dabc dbac dbca adcb dacb dcab dcba

The output from the above program, when converted to strings is:
abcd abdc acbd acdb adbc adcb bacd badc bcad bcda bdac bdca cabd cadb
cbad cbda cdab cdba dabc dacb dbac dbca dcab dcba

Note:

items = [''.join(p) for p in perm('abcd') ]
assert items == sorted(items)
items = list(all_perms('abcd'))
assert items != sorted(items)

 

[Jorgen Grahn]

No "real" concurrency but a generator can be seen as independent thread
of code where the generator code is allowed to run when `next()` is
called and stops itself when it ``yield``\s an object. Sort of
cooperative multitasking.

Sort of ... I find it more useful to see it as an object, or something
with a state. And I think it's a bad idea to rewrite an algorithm
using threads in order to simulate generators.

The name "yield" is often used in concurrent
code like Java's or Io's `yield()` methods.

That's a completely unrelated yield, isn't it?

Meanings (1) and (3) respectively in http://en.wiktionary.org/wiki/yield:
- To give way; to allow another to pass first.
- To produce as return, as from an investment.

/Jorgen