Hello Sean,

Thanks a lot for your reply.

> The previous discussion on Evolve.java got me involved in tweaking it  
> to make it more understandable, modifiable, and subclassable last  
> night.  Allow me to attach a copy of my revised version of the file  
> here.  I do so not because you can use it (it may or may not work  with 
> the current on-line version of ECJ) but because I rearranged the  code a 
> little bit and also included in the comments a BIG LONG  discussion of 
> how the revised code works and how you can use it to  make your own 
> main().  BTW, a basic main() can be constructed in  about ten lines.

I'll study it. I agree with the fact that rewriting the equivalent of 
main in the context of a Web app is not difficult (I did it).

> You'd also do well to read my previous posting about Evolve.java  
> earlier this month. I'm concerned I may be repeating myself a bit.

OK. I'll look for it.

> This is pretty straightforward to do.  More or less the args have two  
> functions.  First, ECJ uses them to determine if you're starting up  
> from checkpoint.  Second, ECJ passes ALL the args (if you're *not*  
> starting from checkpoint) into the ParameterDatabase, which uses them  
> to load itself from the provided file and tack on some command-line- 
> provided arguments.
> 
> That's it!

Understood.

> There's no reason you can't start up ECJ from a parameter database  
> you've constructed on your own.  At the very least you can just make  a 
> blank database and dump a bunch of runtime arguments into it which  
> you've gathered through some other means, and then fire up ECJ using  
> that database.

It was one of my ideas : programatically store the user inputs in the 
parameter database.

> statics will be going away soon probably.  It had exactly one  purpose: 
> to let you stash pointers to statically-declared objects in  order to 
> guarantee they'd get serialized.  We've since gotten rid of  all of our 
> statically-declared objects.  Thus no more need for statics.
> 
> Don't use statics.  If you want to make a global variable, stick in  the 
> prototype of your Problem instance.  Or if you must, subclass  
> SimpleEvolutionState (or whatnot) and add an instance variable.

OK. Good to know this. It would avoid me starting in the wrong direction :-)

> SimpleStatistics maintains the fittest individual of each  population.  
> SimpleStatistics.finalStatistics(...) prints it out at  the end.  
> Subclass from SimpleStatistics to do something else: or you  can make 
> your own Statistics object to maintain this information.

OK. I had this understanding of the logic.


Thanks again for your support

Best regards

Eric