 |
 |
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.