Skip to: Content | Navigation | Footer
Tutorials
Topics:
- Comparing Different Genetic Programming Packages (June 2007)
- ECJ tutorial using Eclipse
- A quick and simple way to write detailed individuals on a file with ECJ
- Project: a light Python API using Strongly-Typed Genetic Programming
Comparing Different Genetic Programming Packages (June 2007)
There exists many packages that make use of Evolutionary Algorithms. Presenting them all would be a very tedious exercice, and I don't pretend to actually know them all. We will focus exclusively on the ones that specifically offer Genetic Programming (GP) functionalities. To gain time, I have chosen to exclude packages using programming languages with a slow learning curve : no c, c++, no perl. This is a bit unfair, because this takes away some very interesting and useful packages such as Lil-GP or Open Beagle, but this also simplifies life greatly if you don't have years of programming experience in these languages. If you really want to go in this direction, have a look at the bottom of the wikipedia page dedicated to GP, and also see this paper from Christian Gagné [1]. Having a limited amount of funding, we discard MATLAB or commercial packages which are anyway not the best option. Now, here is a list of what is left:
To evaluate and compare these packages, we will use several criteria. Some of them come from the paper referenced above, and others are just the result of a painful experience practicing obscure and badly documented packages... Here they are:
- Documentation : if the package is well explained, the documentation is clear and usable, and illustrated with good examples. The most important factor so far, as a package can be brilliant, but unusable due to the lack of explanation on how to use or combine specific features.
- Level of Activity : how active is the forum related to the project. Sooner or later , by using a new package, one gets stuck for some obscure technical reason. The only way to get things done is then to contact the authors or the community via email or forum (unless you want to re-program the package from scratch). An active forum is the indication that any future problems will find solutions.
- Generic Representation : the possibility to define new individual representations without limitation on the data structure used. For example (a bit of a challenge) using a GP based package to represent every individual by a weighted oriented graph with recursive loops... This flexibility is the rarest and the most difficult feature to find so far.
- Generic Fitness : Individual fitness measures should be as independent as possible from representations and selection operations. In evolutionary computation, the fitness function is the most important bit, as it is what makes you converge to a solution. So, needless to say, you must be able to define it, tweak it, and play with it as much as possible without having to recode the representation or the selection operations. An ideal framework would support multiobjective fitness measures. An abstract representation of the fitness value would then include mechanisms to compare two values without knowledge of the concrete
fitness type. - Generic Operations : all kind of fancy genetic selection schemes and operations should be allowed. The classics (e.g. two-parents crossover) are needed, and one might also be able to customize the selection schemes and operations. One should be able to even combine different operations. This suppose that the operations are independant from the representation, and have minimal side effects.
- Parameters management : it is very convenient to be able to modify dynamically parameter values (population size, mutation probabilities, etc.) from a configuration file and a user interface. It also becomes necessary to be able to add new parameters for customized Evolutionary Algorithms (EA).
- Configurable output : there must be a configurable Output to a file. I can't emphasize how vital it is to be able to examine the population generated at every evolution stage, and the fitness of every individual. Additional statistics are also very useful (e.g. in GP applications, tree sizes and depths). Customized statistics are also needed if you need to prove a point efficiently.
The comparaison table is not complete, as I did not have the opportunity to experiment in depth with every package. Anybody whishing to add some information and comment will be very much welcome to email me as it will produce a more complete description of what is available.
| Name | Documentation (weight = 3) |
Activity (weight =2.5) | Generic Representation (weight =2) | Generic Fitness (weight =2) | Generic Operations (weight =2) | Parameters (weight =1.5) | Output (weight =1) | Score |
| ECJ | 6 - good and many examples. The complexity of the package would ask for more detail ,though... | 9 - Excellent. Very active community. Nice people | 5 - The best of the lot (ADFs, ADMs ...) | 8 - Very nice to be able to evaluate the fitness of the sub trees... | 8 | 8 | 8 | 52 |
| JGAP | 6 - better explanations but fewer examples | 8 - Very Good. Large community and active. | 4 - A bit more simple. Lacks some interesting features. | 7 - Simpler but less powerful | 6 - The random generator uses Java.Random which is not very random | 7 | 8 | 43 |
| PushGP | 5 - Good explanation but very general. Detailed stuff is "pythonic"... | 5 - Nice and Cosy. Medium sized community | 3 - Original, but difficult to use ADFs. | 5 - Difficult to get fitness of sub trees... | 8 | 6 | 8 | 40 |
| DRP | 5 - Good explanation but very general. Detailed stuff is "pythonic"... And fewer examples | 4 - Small group. | 3 - Interesting, but incomplete | 4 - Incomplete | 8 | 6 | 8 | 38 |
| JRGP | 4 - Confusing. Java doc mostly | 1 - Dead | 2 - Needs extra work | 5 - Workable | 7 | 6 | 8 | 33 |
| JGPROG | 4 - Confusing. Java doc mostly | 1 - Even more dead | 2 - Needs extra work | 5 - Workable | 7 | 5 | 8 | 32 |
[1] Christian Gagné and Marc Parizeau, Genericity in Evolutionary Computation Software Tools: Principles and Case-Study,International Journal on Artificial Intelligence Tools, vol. 15, no. 2, p. 173-194, April 2006 (http://cgagne.googlepages.com/ijait2006.pdf).
ECJ Tutorial using Eclipse
Preliminary steps :
- install the JAVA Development Kit 1.5, or whatever is the last stable version available...
- install an Integrated Development Environment (a programming tool) adapted to this programming language. I have a preference for Eclipse.
- download ECJ 16 and unzip the file in a folder somewhere.
- create a new JAVA project in Eclipse. Add the Jfreechart, itext and other user libraries required to your project, except ECJ...
- When it is done:
- either right click on your project folder in the package explorer window and select Import. Select File System and browse to find your unzipped folder containing the ECJ classes.
- One alternative way after the project is created, there is an empty src folder, right-clicking on this folder and then import from the level above the folder "ec".
- select everything but the .classpath and .project files. Make sure that the "create selected folder only" is ticked.
- The whole ecj package will be imported. After that you should see source folders names of the type : "ec.app.gui". There should not be any sources with a red cross in front... And put all your ".params" files in the main directory. They should be visible at the bottom of the tree. See the picture below...
- Don't forget to modify the path reference in the beginning of ".params" files when necessary. To do that replace paths of the type: "parent.0 = ../../ec/gp/koza/koza.params" by "parent.0 = koza.params" which is the right path in the eclipse folder. Update any other classpath reference in .param files as well...
One useful tip is to put all "params." files in one so you don't have to go through several parameters files for one run. To do it, make a copy of "ec.params" and append to it successively "simple.params", "koza.params", and your custom parameter file (e.g. "tutorial.params"). Then, take away the lines starting with "parent.0 = ". Working on one unified parameter file will avoid you a lot of troubles... |
- Create your classes (or copy the content of the classes in one tutorial if you want to experiment a little bit) and ".params".
- Go to Run -> Run... in the upper part of Eclipse. Select the main class like here:
- You can add Arguments for the command line this way (In this example, the VM arguements are tuned for at least 1Gig of RAM - the rest is of no real interest for this example):
- You are now ready for starting experimenting with evolution !! :)
A quick and simple way to write detailed individuals on a file with ECJ
No need for using "statistics" classes, or other complications. You can just introduce the following piece of code in the evaluate() method of your class that is extending GPProblem. Example with a modification of tutorial 4 (see the code in bold-red):
/*
Copyright 2006 by Sean Luke
Licensed under the Academic Free License version 3.0
See the file "LICENSE" for more information
*/
package ec.app.tutorial4;
import ec.util.*;
import ec.*;
import ec.gp.*;
import ec.gp.koza.*;
import ec.simple.*;
public class MultiValuedRegression extends GPProblem implements SimpleProblemForm{
public double currentX;
public double currentY;
public DoubleData input;
public Object clone(){
MultiValuedRegression newobj = (MultiValuedRegression) (super.clone());
newobj.input = (DoubleData)(input.clone());
return newobj;
}
public void setup(final EvolutionState state,final Parameter base){
// very important, remember this
super.setup(state,base);
// set up our input -- don't want to use the default base, it's unsafe here
input = (DoubleData) state.parameters.getInstanceForParameterEq(
base.push(P_DATA), null, DoubleData.class);
input.setup(state,base.push(P_DATA));
}
public void evaluate(final EvolutionState state, final Individual ind, final int threadnum){
if (!ind.evaluated) // don't bother reevaluating{
int hits = 0;
double sum = 0.0;
double expectedResult;
double result;
try{
PrintWriter writer = new PrintWriter(new PrintWriter(new FileWriter("myOutput", true)));
writer.write("\n ============================= \n");
for (int y=0;y<10;y++){
currentX = state.random[threadnum].nextDouble();
currentY = state.random[threadnum].nextDouble();
expectedResult = currentX*currentX*currentY + currentX*currentY + currentY;
((GPIndividual)ind).trees[0].child.eval(
state,threadnum,input,stack,((GPIndividual)ind),this);
result = Math.abs(expectedResult - input.x);
if (result <= 0.01) hits++;
sum += result;
}
// the fitness better be KozaFitness!
KozaFitness f = ((KozaFitness)ind.fitness);
f.setStandardizedFitness(state,(float)sum);
f.hits = hits;
ind.evaluated = true;
ind.printIndividual(state, writer); // print the detail of the individual
writer.close();
} catch (Exception e){System.err.println ("Error writing to file");}
}
}
}
Project (a light Python API) pySTEP: Python Strongly Typed gEnetic Programming
A functional version of the pySTEP distribution is now available.
See the pySTEP website :)
Problem: Lack of simplicity and flexibility of existing Genetic Programming APIs when using Strongly-Typed and Grammar based structures.
The goal is: create a simple and flexible Strongly-Typed Genetic Programming API using a simple and flexible programming language : Python.
The goal is NOT : a super-optimized, hyper-performant marvel of software engineering that computes huge populations using obfuscated code. We will be happy to play with relatively small populations of let say 10000 individuals maximum. What we want is not raw power, but rather control on how we investigate the search space by establishing elaborate constraints and structures defining the shapes of the trees generated.
This would be a package that allows you to evolve any kind of weird graph, object, hierachical and complex composite structure in general, given this thing can be encoded inside a tree structure.
In Python, the following tree could be represented by a nested list:
Nested list representation(Assumption: First element of a list or a nested list is always a head node) :
individual = ['A', ['B', ['D', 'H', 'I'], 'E'], ['C','F', 'G']]
This simple representation is the starting point of the project.
.Note: ECJ code might be outdated as the last time I had a look on ECJ was in mid 2007...