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