Hi Chris.  You're correct, the problem could well be that  
readRootedTree is marching through the function set, asking each node  
in turn to try to load at that position, and your earlier predicate  
is gleefully loading because it matched its name.  The problem  
doesn't lie in readRootedTree, but in GPNode.readNode(DecodeReturn)

What's fundamentally triggering this is that you're using the same  
node twice.  This isn't *really* a bug per se, though I should check  
to see if there are multiple usages of the same GPNode class in a  
given function set.

So how to work around it?  Here's one way:

1. [easier] override toString() to print out not only the node's  
"name", but maybe the constraint number or some other unique  
identifier, so it looks like this perhaps:

     public String toString()
         { return ERC_PREFIX + name() + "{" + constraints + "}[" +  
encode() + "]"; }

This of course only works if you don't change your constraints  
orderings.

2. Override edu.jhuapl.PredicateERCNode.readNode to be just like  
ERC.readNode but instead change the line to:

	String str2 = ERC_PREFIX + name() + "{" + constraints + "}[";

... so it looks for that particular node.

You could of course detect what "kind" of constraints you're  
expecting and put something smarter than just a constraints number in  
there, but something like this might work.

Sean


On Apr 17, 2007, at 12:08 PM, Chris McCubbin wrote:

> Ok, I am now attempting to read in an individual using a text  
> stream but I
> seem to be having a tough issue. I think the problem is that I have  
> a node
> type, "predicate", which is a non-terminal ERC node. This predicate  
> node can
> have many different constraints. It always has 3 children but the 3  
> children
> can be of three different types, say person, place, or thing, or the
> emptyVariable (all terminals, and all ERC's except the empty  
> variable). The
> way I did this was create a whole lot of lines in the parameter  
> file that
> look like these:
>
> //this is the first one in the file btw.
> gp.nc.10 = ec.gp.GPNodeConstraints
> gp.nc.10.name = P-predicateConstraints
> gp.nc.10.returns = disjunction
> gp.nc.10.size = 3
> gp.nc.10.child.0 = person
> gp.nc.10.child.1 = emptyVariable
> gp.nc.10.child.2 = emptyVariable
>
> gp.fs.0.func.10 = edu.jhuapl.PredicateERCNode
> gp.fs.0.func.10.nc = P-predicateConstraints
>
> gp.nc.14 = ec.gp.GPNodeConstraints
> gp.nc.14.name = PL-predicateConstraints
> gp.nc.14.returns = disjunction
> gp.nc.14.size = 3
> gp.nc.14.child.0 = person
> gp.nc.14.child.1 = location
> gp.nc.14.child.2 = emptyVariable
>
> gp.fs.0.func.14 = edu.jhuapl.PredicateERCNode
> gp.fs.0.func.14.nc = PL-predicateConstraints
>
> ...etc.
>
> Before you ask, the predicate and children are ERC's because the  
> predicate
> itself can vary, for example we might have "cute(person1, empty,  
> empty)" or
> "tall(person2, empty, empty)" as two concrete predicates that are
> implemented by func.10 above.
>
> When the readRootedTree method in GPNode gets executed on a  
> predicate node,
> I don't think it can determine which one of the constraints it is  
> really
> supposed to be using so it just picks the first one and always  
> expects the
> first child to be a "person" terminal. When it sees something else,  
> it gives
> me the "I came across a symbol which I could not match up with a  
> type-valid
> node..." error.
>
> I believe the way to fix this may be to somehow modify the way my  
> predicate
> ERC reads itself in, but I could use some hints on how to do that.  
> Is this
> making any sense, or am I just way off base?
>
> Thanks,
> Chris
>
>
> Sean wrote:
>
> ECJ can load whole populations or create them from scratch, neither  
> of which
> you want in this case.  This is most easily done with a new
> subclass of Subpopulation, overriding Subpopulation.populate(...).
> Probably the easiest approach would be:
>
>  - call super.populate(...) to fill the population with random  
> individuals
>  - overwrite individuals[0] with your custom individual, perhaps  
> loaded from
> a file (see the two Individual.readIndividual(...) methods), or by
> constructing your individual programmatically and sticking it in.
>
> ECJ's got several ways of reading and writing individuals, using
> DataInput/DataOutput, or text streams.