On Jan 2, 2013, at 4:33 PM, Mehran Maghoumi wrote:
> I should have mentioned that I only intend to modify ECJ's GP package so I think it is easy enough to keep track of the "parent" (my final goal is to see the impact of the new crossover strategy on program bloat)
> I would like to think of it as follows (correct me if I'm wrong):
> In the "produce" method of the class -say- "CrossoverPipeline", after all of the constraints are checked, the newly created individuals (which are created using a point-crossover) are added to the population in those last lines of code (in the section that you have commented):
> // add the individuals to the population
> inds[q] = j1;
> if (q<n+start && !tossSecondParent)
> inds[q] = j2;
> so basically the j1 and j2 individuals should be compared against parents and parents and if they are fitter, then they are added to "inds" array.
> Am I on the right track?
You could hack it this way for your purposes, but keep in mind that it only makes sense if parents and parents are actually previous members of the population. They might not be if the CrossoverPipeline's sources aren't selection methods but rather are *other pipelines* (maybe a mutator or something). So take care that they're not -- or double check the sources programmatically to make sure they're instances of SelectionMethod.
Then you could just do this (as a quick hack, assuming you have only one subpopulation):
SimpleProblemForm problem = (SimpleProblemForm)(state.evaluator.p_problem.clone());
// you can evaluate a single individual with a hack like this:
problem.evaluate(state, theIndividual, 0, threadnum)