EO, the class library and its applications

All the EO ideas have been put in practice in the EO class library, an Open Source C++ library which is available from http://geneura.ugr.es/~jmerelo/EO.html. Current version is 0.8.4, which means it is not really complete. EO needs an ANSI-C++ compliant compiler, such as the Free Software Foundation egcs or gcc, in Linux, other Unix flavours or the CygWin environment for Win95/98/NT. It works also with commercial compilers such as Microsoft's Visual C++ 6.0 and Inprise's Borland C++ Builder 3.0.

The main features of EO (the class library, which we will call EOlib) are:

• EOs, or evolving objects, play the role of chromosomes. Several different EOs are included in the distribution: bitstring, character string, vectors of any kind, and feedforward neural nets.

  Figure: Class hierarchy for the "chromosomes", which include raw evolving objects (EOBase), and several other kind of chromosomes. New evolving objects can be defined by subclassing any of them.

  

• Genetic operators are grouped in two different kinds: generic and specific. Generic operators can be applied to many classes of EOs. For instance, a permutation operator can be applied to any object that subclasses a generic vector (eoVector), as can a crossover operator. Other operators, like mutation, are mostly EO-specific: a bitstring mutates in quite a different way from a floating-point 2-D array. Since C++ is an strongly-typed language, trying to apply an operator that does not suit an EO is an error that is caught at compile time. This is an specific feature of this implementation of EO, but it can be also used in other languages by using protocols (in Objective C) or interfaces (in Java or Visual Basic). Operators are objects that behave as functions, that is, functors, which means they are applied in this way:

  eoString aString;
  eoTranspose<eoString> transposer;
  transposer(aString);
  

  Figure: Hierarchy of ``genetic'' operators, which includes unary (mutation-like), binary (crossover-like), and n-ary (orgy-like) operators. All of them are specific for a class of EO and its subclasses, but some of them are more specific than others: for instance, EOFloatArrayMutateByPercentage can just be applied to evolving floating point arrays.

  

  
  Having operators outside evolving objects makes operating with them easier. Since they are classes, they can be subclassed by the user to create his or her own operators, which will become full-fledged operators from the point of view of the rest of the EO class library. Besides, operators have a very simple interface: they just have to redefine operator () with one, two or a vector of operands.
• Population level operators are generic, and take one or two population objects and create a new one from them. These population level operators thus include selection, replacement, and can be modifed using fitness scaling, crowding or any other reproduction strategy.
• Algorithms are also objects, and EO provides algorithm objects such as eoES (evolution strategy) eoEasyGA (a simple but flexible GA), and eoSGA (Goldberg's Simple Genetic Algorithm), as well as eoSA (simulated annealing).

  Figure: Class hierarchy for the algorithm objects; algorithms are applied to population objects, evolving them until a condition is met. Several algorithms have already been implemented: simulated annealing, Goldberg's Simple Genetic Algorithm, an easy-to-use but flexible GA, Evolution Strategies and age-based GAs.

  

Our team has provided facilities to make EO an Open Source effort: a web page, a mailing list and CVS access to the source tree are all provided.

We intend also to provide an object repository, so that if something is programmed in EO, the object class can be sent to us (or posted on any other web site) so that the EC community can reuse it. This would also improve the reproducibility of EC results: a good practice would be to leave the particular object that has been used to program an EC solution in this repository, so that anybody can check the results and profit from them.

Most times, and to use EO in a C++ program, the only thing that has to be modified is the fitness computation function; the rest of the EC algorithm is just a matter of picking and choosing.

So far, EO has been used by our team in several experiments, evolving BP neural nets and evolving mastermind solutions. In the first case [13], multilayer perceptrons were evolved; no binary or floating point vector representation was used; the objects that were evolved were the multilayer perceptrons themselves. The EO class was used for the population-level operators, but new diversity-generation operators had to be designed: add or eliminate a hidden layer neuron, hidden layer crossover, and mutate initial weights. In one case, the backpropagation training algorithm was used also as mutation operator [14]. It was very easy and straightforward to adapt this problem to EO: the new mutation operators were given the same rights as the ``native'' mutation operators, which could not be used in this case.

In the case of mastermind, a GA was programmed to find the hidden combination, improving results obtained in previous implementations. Part of the success was due to the fact that the subject of evolution were the mastermind solutions themselves, that is, substituting colors by numbers. The genetic operators were also adapted to these objects: a permutation and a creep operator, which substituted a number (color) by the next, and the last by the first. A huge improvement was obtained; the algorithm explored only a 25% of the space that was explored before, that is, around 2% of the total search space, and thus obtained solutions much faster.

It cannot be claimed that EO obtains always better results than existing EC frameworks, but as EO includes all of them, it obtains at least as good results; with the added advantage that any representation or algorithm can be checked against any other, withouth needing to use different programs.