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