January 2006


Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Eric Pascual <[log in to unmask]>
Reply To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Thu, 26 Jan 2006 13:33:00 +0100
text/plain (66 lines)
Hello Sean,

Thanks a lot for your reply.

> The previous discussion on 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
> 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!


> 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