Subject: | |
From: | |
Reply To: | |
Date: | Wed, 25 Jan 2006 17:29:41 -0500 |
Content-Type: | multipart/mixed |
Parts/Attachments: |
|
|
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
|
|
|