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