Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #46074
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: Solving the problem of mutual recursion |
| Date | 2013-05-26 18:09 +0300 |
| Organization | University of Helsinki |
| Message-ID | <qota9nhu6ag.fsf@ruuvi.it.helsinki.fi> (permalink) |
| References | <55942e65-e4a5-45fc-b2fc-ceb4020959dd@k4g2000vba.googlegroups.com> |
Peter Brooks writes:
> I'm not sure if this'll interest anybody, but I expect that I'm
> going to get some mutual recursion in my simulation, so I needed to
...
> returned, then this solution won't help you. Often, though, you're
> not interested in what's returned and would just like the routine to
> exit once it's called itself, or another process, recursively.
>
> If that's the case, this solution, using threads, allows you to have
> functions call themselves, or each other, indefinitely. It works OK
> on a macbook pro and the thread count varies from 2-3, so it handles
... hard to resist ... but somehow I manage ... whew ...
A light-weighter way is to have each task end by assigning the next
task and returning, instead of calling the next task directly. When a
task returns, a driver loop will call the assigned task, which again
does a bounded amount of work, assigns the next task, and returns.
Tasks can even pass parameters in the same way.
Like so, Dr. Fred keeps adding to a pile as long as there is a pile,
and Mr. Jim keeps taking from it as long as it's there to take from:
from random import choice
def fred():
global fun, arg
print('Fred adds 1')
fun, arg = choice((fred, jim)), arg + 1
def jim():
global fun, arg
print('Jim takes 1')
fun, arg = choice((fred, jim)), arg - 1
if __name__ == '__main__':
fun, arg = choice((fred, jim)), 3
while arg:
print('Pile is', arg, end = '\t')
fun()
else:
print('Pile is gone')
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 04:49 -0700
Re: Solving the problem of mutual recursion Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-05-26 18:09 +0300
Re: Solving the problem of mutual recursion Roy Smith <roy@panix.com> - 2013-05-26 11:23 -0400
Re: Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 10:21 -0700
RE: Solving the problem of mutual recursion Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-26 21:09 +0300
Re: Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 11:13 -0700
RE: Solving the problem of mutual recursion Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-26 21:22 +0300
Re: Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 12:05 -0700
Re: Solving the problem of mutual recursion Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-26 13:35 -0600
Re: Solving the problem of mutual recursion Chris Angelico <rosuav@gmail.com> - 2013-05-27 08:16 +1000
Re: Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 21:36 -0700
Re: Solving the problem of mutual recursion Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-27 00:07 -0600
Re: Solving the problem of mutual recursion Chris Angelico <rosuav@gmail.com> - 2013-05-27 17:37 +1000
Re: Solving the problem of mutual recursion Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-27 00:19 -0600
Re: Solving the problem of mutual recursion Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-27 01:04 -0600
csiph-web