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