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.









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.





On Jan 24, 2006, at 11:44 AM, Eric Pascual wrote:



> I've some ideas about how to implement this, but I'm not sure they are

> "compliants" with ECJ philosophy and architecture. Here they are :

>

> 1/ sub-class Evolve and implement a method doing more or less what  

> main

> does, buth replacing the command line args mechanism with something  

> using

> webapp properties for instance. This method will be called by the

> doPost/doGet handler



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!



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.





> 2/ have the end-users inputs be transmitted as an object stored  

> into the

> statics vector of EvolutionState before firing ECJ search



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.





> 3/ when iterations are over, scan population to get the fittest  

> individual.

> I have a problem with this, because since ECJ is quite a powerfull and

> flexible software, I would have imagined that there was some  

> qhicker way to

> retreive the best individual of a population. I'm pretty sure I'm  

> overlooked

> something and that there is a built-in way to do this



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.



Sean