Recursion bug...

[ex_ottoyuhr]

To start with, I'm new at Python, so if this is something relatively
ordinary or a symptom of thinking in C++, I apologize...

Anyhow, I'm currently trying to write a means of generating
genetic-programming functions in Python; the details would be a little
much for a Usenet post, but suffice it to say that it would involve
trees of objects with an opcode and a variable number, between in this
case 0 and 3, of 'arguments' -- also objects of the same sort. As a
function to implement them, I'm doing something to the effect of this:

max_opcode = ( 20, )
max_with_arguments = ( 15, )

class TreeCommand:
opcode = 0
children = []
def __init__(self, anOpcode) :
opcode = anOpcode

def MakeTreeCommand( maxdepth, currdepth ) :
if ( currdepth == 0 ) :
toRet = TreeCommand(random.randint(0, max_with_arguments[0])
elif ( maxdepth == currdepth ) :
toRet = TreeCommand(random.randint(max_with_arguments[0]+1,
max_opcode[0]))
else :
toRet = TreeCommand(random.randint(0, max_opcode[0]))

if ( toRet.opcode <= max_with_arguments[0] ) :
childrenRequired = something_greater_than_0
else :
childrenRequired = 0

generated = 0

while ( generated < childrenRequired ) :
toRet.children.append(MakeTreeCommand(maxdepth, currdepth + 1))

return toRet

Sorry to have given such a long example... But anyways, the problem is
that, while I think this should generate a number of children for each
toRet equivalent to the required number of children, it's actually
appending all children generated in the function to the 'root' toRet
rather than to child functions -- so that if I ask for a tree with
depth 2, and the root would have 2 arguments, the first child would
have 1, and the second child would have 2, the result is a root with a
5-argument-long children and two child functions with 0-argument ones.
There's some other strange stuff going on here, too; in particular,
with one particular opcode, toRet is assigned a member 'value' which is
randomly generated between 0 and 10,000. All toRets assigned value seem
to be ending up with the same result...

Could anyone explain what I'm doing wrong? I'm beginning to suspect
that Python scope rules must not work like my native C++; have I made a
common mistake?

 

[Devan L]

To start with, I'm new at Python, so if this is something relatively
ordinary or a symptom of thinking in C++, I apologize...

Anyhow, I'm currently trying to write a means of generating
genetic-programming functions in Python; the details would be a little
much for a Usenet post, but suffice it to say that it would involve
trees of objects with an opcode and a variable number, between in this
case 0 and 3, of 'arguments' -- also objects of the same sort. As a
function to implement them, I'm doing something to the effect of this:

[ex_ottoyuhr's code]

Sorry to have given such a long example... But anyways, the problem is
that, while I think this should generate a number of children for each
toRet equivalent to the required number of children, it's actually
appending all children generated in the function to the 'root' toRet
rather than to child functions -- so that if I ask for a tree with
depth 2, and the root would have 2 arguments, the first child would
have 1, and the second child would have 2, the result is a root with a
5-argument-long children and two child functions with 0-argument ones.
There's some other strange stuff going on here, too; in particular,
with one particular opcode, toRet is assigned a member 'value' which is
randomly generated between 0 and 10,000. All toRets assigned value seem
to be ending up with the same result...

Could anyone explain what I'm doing wrong? I'm beginning to suspect
that Python scope rules must not work like my native C++; have I made a
common mistake?

Well, for one, in your __init__ method, you never do anything with
anOpcode. You simply assign the name 'opcode' to anOpcode. The reason
why everything is the same is that you're accessing
TreeCommand.children or Treecommand.opcode, which is shared by all
instances unless you assign to it. And you never increment generated,
so I don't see why the while loop would ever end, unless you
intentionally wanted that. Try this code instead:

max_opcode = 20
max_with_args = 15

class TreeCommand:
def __init__(self, opcode) :
self.opcode = opcode
self.children = []

def MakeTreeCommand(depth, maxdepth) :
if depth == 0:
command = TreeCommand(random.randint(0, max_with_args)
elif depth == maxdepth:
command = TreeCommand(random.randint(max_with_args+1,
max_opcode))
else:
command = TreeCommand(random.randint(0, max_opcode))

if command.opcode <= max_with_args:
children_required = something_greater_than_0
else:
children_required = 0

generated = 0

for i in range(children_required):
command.children.append(MakeTreeCommand(depth+1, maxdepth))

return command

 

[bonono]

class TreeCommand:
opcode = 0
children = []
def __init__(self, anOpcode) :
opcode = anOpcode

opcode and children in this case is more like "class" variable in C++.
If you want "instance" variable, you need to do it as self.opcode,
self.children, in all methods.

 

[ex_ottoyuhr]

Devan L wrote:

Well, for one, in your __init__ method, you never do anything with
anOpcode. You simply assign the name 'opcode' to anOpcode. The reason
why everything is the same is that you're accessing
TreeCommand.children or Treecommand.opcode, which is shared by all
instances unless you assign to it.

OK, _that's_ what I was doing wrong... Thanks a lot. I suspected it
might be a product of C++-isms and being self-taught in the language...

And you never increment generated,
so I don't see why the while loop would ever end, unless you
intentionally wanted that.

I just forgot to add that part -- I was demi-transcribing it, you might
put it, as opposed to actually copying. There were a few bugs in that
part...

Try this code instead:

<snip>

 

[ex_ottoyuhr]

class TreeCommand:
opcode = 0
children = []
def __init__(self, anOpcode) :
opcode = anOpcode

opcode and children in this case is more like "class" variable in C++.
If you want "instance" variable, you need to do it as self.opcode,
self.children, in all methods.

Thanks a lot. I'm sorry to have bothered you and the newsgroup with
such a simple problem, but then again, I'm glad it was simple, and I
suppose that's what newsgroups are for...