SimpleBreeder (starting around line 94) uses an overly elaborate bit of 
math to divide the subpopulation into chunks and hand each chunk off to 
a thread.  Unless you're doing something fairly funky in 
PlagueSimpleBreeder, this is the primary place where something is going 
wrong.

Questions:

- Are you doing multithreaded breeding?  If so, how many threads?

- How large is the subpopulation when this error occurs?

- What does PlagueSimpleBreeder.breedPopulation do before it calls 
super.breedPopulation?

Sean


Daniel Lombraña González wrote:
> Hi,
> 
> I'm going to check the ES package and try it. Adjoining is the
> backtrace (I'm using GNU/Linux with jre 1.6)
> 
> Daniel
> 
> 
> | ECJ
> | An evolutionary computation system (version 18)
> | By Sean Luke
> | Contributors: L. Panait, G. Balan, S. Paus, Z. Skolicki, R.
> Kicinger, E. Popovici,
> |               J. Harrison, J. Bassett, R. Hubley, A. Desai, and A. Chircop
> | URL: http://cs.gmu.edu/~eclab/projects/ecj/
> | Mail: [log in to unmask]
> |       (better: join ECJ-INTEREST at URL above)
> | Date: June 23, 2008
> | Current Java: 1.6.0_0 / OpenJDK Server VM-1.6.0_0-b11
> | Required Minimum Java: 1.3
> 
> 
> Threads:  breed/1 eval/1
> Seed: 4357
> Job: 0
> Setting up
> Processing GP Types
> Processing GP Node Constraints
> Processing GP Function Sets
> Processing GP Tree Constraints
> Initializing Generation 0
> Subpop 0 best fitness of generation: Fitness: Raw=24.0 Adjusted=0.04 Hits=40
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 18
> 	at ec.gp.koza.CrossoverPipeline.produce(CrossoverPipeline.java:422)
> 	at ec.breed.MultiBreedingPipeline.produce(MultiBreedingPipeline.java:130)
> 	at ec.simple.SimpleBreeder.breedPopChunk(SimpleBreeder.java:182)
> 	at ec.simple.SimpleBreeder.breedPopulation(SimpleBreeder.java:119)
> 	at ec.simple.PlagueSimpleBreeder.breedPopulation(PlagueSimpleBreeder.java:25)
> 	at ec.simple.SimpleEvolutionState.evolve(SimpleEvolutionState.java:119)
> 	at ec.EvolutionState.run(EvolutionState.java:371)
> 	at ec.Evolve.main(Evolve.java:648)
> 
> 
> On Mon, Oct 20, 2008 at 3:02 PM, Sean Luke <[log in to unmask]> wrote:
>> I'm sorry Daniel, I can't do much here without the full stack backtrace
>> printed out, not just the exception.  Can you provide that?
>>
>> At any rate, nowhere should ECJ be relying on initial population size
>> conditions: that would definitely be a bug.  Populations can and do resize
>> themselves: in fact I have an entire paper relying on that fact.
>>  (http://www.cs.bham.ac.uk/~wbl/biblio/gp-html/luke_2003_gecco.html) And the
>> ES package does it as a matter of course.
>>
>> Sean
>>
>> Daniel Lombraña González wrote:
>>> Hi to all,
>>>
>>> I'm trying to use ECJ with GP and dynamic populations. I have been
>>> searching in the mailing list and I found the following conversation:
>>>
>>> https://listserv.gmu.edu/cgi-bin/wa?A2=ind0404&L=ECJ-INTEREST-L&P=R72&I=-3
>>>
>>> I have tried that solution, but I get an error when the
>>> CrossoverPipeline tries to create two new offsprings. The obtained
>>> error is the following one:
>>>
>>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 18
>>>
>>> It seems that the variable "q" is getting out of the bound in the inds
>>> array. I don't know how to fix this. It seems that the problem relies
>>> on the initial population length = 20, which is not varied at all
>>> during the evolution.
>>>
>>> Any ideas?
>>>
>>> PS: By the way, if using the proposed solution you increase the size
>>> of the subpopulation you get an error because ECJ tries to compute the
>>> fitness of a null individual :)
>>>
>>> --
>>>
>>> ··························································································································································
>>> PhD Candidate
>>> Cátedra Ceta-Ciemat de la Universidad de Extremadura
>>> http://gea.unex.es/catedra-ceta-ciemat/
>>> Universidad de Extremadura
>>>
>>> ··························································································································································
>>> Por favor, NO utilice formatos de archivo propietarios para el
>>> intercambio de documentos, como DOC y XLS, sino HTML, RTF, TXT, CSV
>>> o cualquier otro que no obligue a utilizar un programa de un
>>> fabricante concreto para tratar la información contenida en él.
>>>
>>> ··························································································································································
>>>
>>>
>>>
> 
> 
>