Subject: | |
From: | |
Reply To: | |
Date: | Thu, 26 Jan 2006 13:33:00 +0100 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|