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)