EO - The Evolving Objects Library A Complete Genetic Algorithm Framework

powemryologistAI and Robotics

Oct 23, 2013 (4 years and 5 months ago)



The Evolving Objects

A Complete Genetic Algorithm

CPSC 642: Artificial Intelligence II

James Maxlow

Intended Purpose

The Evolving Objects Library is intended to be a complete
solution for those
wishing to use genetic algorit
hms to solve problems. The project stretches from simple,
built genetic algorithm code whose parameters (crossover rate, mutation rate, etc.)
can be modified for a user’s needs, to a pre
compiled fully
customizable system where
decisions on parameters
can be set
at run time
, to a framework that allows custom
representations and operators to be created with a minimum of code writing.

At every
level, steps have been taken to provide users with code that simplifies their work and
speeds their use of the fr

output procedures, file
based or command
input, bitstring or real
valued genomes, support for GNUplot for interpreting results, and
more. These provisions are written through extensive use of template
based object
oriented implementati
ons, which is the secret to the immense customizations levels
available to users.

Going beyond simply making these tools
, the Evolving Objects Library also
contains several HTML
based tutorials that guide the user from using the simplest
ntations through creating their own representations. The code itself is also well
documented for those that like to edit code without a guide.

Obtaining the Software

The latest build of the EO software can be found at
This is the
site for

downloading the software

because a new build is uploaded every
, although it is also available at
. It is covered
by the GNU General Public License, which in effect means tha
t it can be used free of
charge, with or without modifications. However, if you release a
version of the
software to the public that has been modified, yo
u must also release the source code
, with
your changes, to the public

More information can be found at

Once the build has been downloaded, unzipped, and

untarred, the user must a)run the
configuration script autogen.sh, and b)use ‘make’ or ‘make lib’ to compile

the various
components. It is notable that this compilation takes several minutes or more, depending
on the speed of the system (‘make lib’ takes
less time, but not by much.) The total disk
usage at this point is around 47


on a Unix system
, but additional space is
required to compile the individual tutorial programs.

Autoconfig is needed to install using
this method.

Note that the downloa
d works on Unix, Linux, and Windows
, being functional with
gcc, g++, CygWin, Visual C++ 5, and Borland Builder compilers / integrated
development environments
This makes the software very robust, and ideal for cross
platform development, if that is req
However, for the purposes of this report,
I only
tested it on a Solaris system.

Sources of Information

The primary source of information for usage of the library can be found in the form of
based tutorial files in the Tutorial directory of
the installation. These files walk
the user through using and customizing the library from a basic level through
progressively more complicated but powerful levels. The files are extensively cross
referenced, however it should be noted that some sections a
re incomplete (the software
hasn’t reached version 1.0 yet.)

The code itself is also liberally documented, though it is
doubtful that a user could get a good sense of how customizable the framework is just by
reading the source code.

There is also a set o
f documentation in the installation that would be generated through
the use of Doxygen, but I have not been able to investigate that option. Furthermore,
despite having at presence at SourceForge, the discussion forums for EO are virtually



order to judge how easy it would be to use the framework to actually solve a problem,
I implemented the 8
Queens puzzle solver and the U.S. Map 4
color puzzle solver (the
code of which I had already implemented with GALib.)

For the 8
Queens, u
sing the fir
tutorial file as a base, there were only two things I had to do. First, I had to set the
parameters in the

// all parameters are hard

const unsigned int SEED = 42; // seed for random number generator

const unsigned int T_SIZE =
3; // size for tournament selection

const unsigned int VEC_SIZE = 16; // Number of bits in genotypes

const unsigned int POP_SIZE = 100; // Size of population

const unsigned int MAX_GEN = 400; // Maximum number of generation before STOP

t float CROSS_RATE = 0.8; // Crossover rate

const double P_MUT_PER_BIT = 0.01; // probability of bit
flip mutation

const float MUT_RATE = 1.0; // mutation rate

Second, I had to use my own fitness function to replace the one given in the



// a simple fitness function that computes the number of ones of a bitstring

// @param _indi A biststring individual

double binary_value(const Indi & _indi)


double sum = 0;

for (unsigned i = 0; i < _indi.size(); i++)

sum += _indi[i];

return sum;


In transferring the code from GALib, length was replaced by _indi.size(), and _indi[x]
replaced chromosome.gene(x)

meaning a line by line port was quick

and easy.

compiled and ran the program to satisfactory results.

For the map solver, I decided to try the precompiled, input
d parameter setting of
tutorial 4. First, I set up my fitness function in a file called binary_value.h, then I
d the file BitEA.cpp. I ran this once based on the default values, which created an
output file containing all of the parameters. I edited this file by changing the parameters
to match my GALib implementation, then ran the program again

without recompili

using the file as an input for the program via a command line switch. This showed that I
could, in the course of solving any given problem, change the genetic algorithm
parameters as desired without spending time recompiling the program.

Problem Sol
ving Power

Because EO is a code library, its problem solving domain is only limited by what the user
can do with C++, and what kind of problems genetic algorithms can solve.

As it is
completely customizable, it is applicable to any genome representation t
hat C++ could
possibly support. The template system and object
oriented implementation provide
additional flexibil
ity and robustness for the user, as do the extensive pre
built command
line and file based input / parameter setting capabilities.

The fact t
hat EO will run on Linux, Unix, and Windows platforms with a variety of

increase its power from the user’s perspective.

It can be used by
development teams on different platforms, requiring only a simple recompile in most
cases (platform spe
cific optimizations set by the user would have to be changed if they
were used, of course.)


With only two examples to benchmark, I’m not ready to draw overarching conclusions
about the speed at which EO code operates, but in my limited expe
rience, there is no
significant performance difference between my EO implementations and GALib
implementations. Originally, my 8
Queens puzzle solver took between 3 and 10 seconds
to find a solution, or proceed through all of its generations, with most of
the runs centered
around 5
7 seconds. The same solver implemented in EO ran between 4 and 11 seconds,
with most, as with GALib, centered around the six second mark.

The U.S. Map 4
color puzzle solver had run very fast, at times, under GALib, with some
utions being found within 3 seconds, and most coming within 6 seconds. Similar
results were found when it was implemented in EO, though the fastest solution came at
about the 4 second mark. Other EO generated solutions came within 6
7 seconds.

In both puz
zle solving algorithms, the primary function of the fitness functions was to
serially traverse the genome to compare subsets of values. From that point of view, the
two algorithms were very similar, and hence it follows that if GALib and EO performed
arly on one puzzle, they would also perform similarly on the other. In other words,
using two or more dissimilar problems would have provided more valuable
benchmarking results. Still, given that both GALib and EO are written in C++, both use
an object
ented system, and both follow the same population generation
> population

> selection / reproduction / mutation process, I would expect that in terms of
runtime speed, neither would have a compelling advantage over the other.