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;
> q++;
>
> if (q<n+start && !tossSecondParent)
> {
> inds[q] = j2;
> q++;
> }
>
> so basically the j1 and j2 individuals should be compared against parents[0] and parents[1] 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[0] and parents[1] 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)
Sean
