ECJ-INTEREST-L Archives

January 2006

ECJ-INTEREST-L@LISTSERV.GMU.EDU

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
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Wed, 25 Jan 2006 17:29:41 -0500
Content-Type:
multipart/mixed
Parts/Attachments:
text/plain (558 bytes) , Evolve.java (26 kB) , text/plain (26 kB)
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

ATOM RSS1 RSS2