EO - The Evolving Objects Library A Complete Genetic Algorithm Framework

powemryologistAI and Robotics

Oct 23, 2013 (3 years and 7 months ago)

59 views

EO
-

The Evolving Objects
Lib
r
ary

A Complete Genetic Algorithm
Framework


CPSC 642: Artificial Intelligence II

James Maxlow




Intended Purpose


The Evolving Objects Library is intended to be a complete
C++
solution for those
wishing to use genetic algorit
hms to solve problems. The project stretches from simple,
pre
-
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
amework
-

output procedures, file
-
based or command
-
line
-
based
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
available
, the Evolving Objects Library also
contains several HTML
-
based tutorials that guide the user from using the simplest
impleme
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
http://garfield.liacs.nl/eo/
.
This is the
recommended
site for

downloading the software

because a new build is uploaded every
night
, although it is also available at
https://sourceforge.net
/projects/eodev/
. 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
compiled
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
http://www.gnu.org/licenses/licenses.html
.


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

megabytes

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
the
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
uired.
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
HTML
-
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
empty.



Use


In

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
st
tutorial file as a base, there were only two things I had to do. First, I had to set the
parameters in the
code
:



// all parameters are hard
-
coded!


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


cons
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
co
de
:


// EVAL

//
-----------------------------------------------------------------------------

// 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.

I
compiled and ran the program to satisfactory results.


For the map solver, I decided to try the precompiled, input
-
file
-
base
d parameter setting of
tutorial 4. First, I set up my fitness function in a file called binary_value.h, then I
compile
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
ng
-

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
compilers
does

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.)





Efficiency


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
sol
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
simil
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
-
ori
ented system, and both follow the same population generation
-
> population
evaluation
-

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