502 lines
30 KiB
HTML
502 lines
30 KiB
HTML
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<meta name="GENERATOR" content="Mozilla/4.78 [en] (X11; U; Linux 2.4.7-10 i686) [Netscape]">
|
|
<title>EO Programming guide</title>
|
|
</head>
|
|
<body text="#000000" link="#0000EE" vlink="#551A8B" alink="#FF0000" background="beige009.jpg">
|
|
<b><font color="#CC0000">General: </font></b><a href="eoTutorial.html">Tutorial
|
|
main page </a>-
|
|
<a href="eoTopDown.html">Algorithm-Based</a> - <a href="eoBottomUp.html">Component-Based</a>
|
|
- <a href="eoProgramming.html">Programming hints</a> - <font face="Arial,Helvetica"><a href="../../doc/html/index.html">EO
|
|
documentation</a></font>
|
|
<br>
|
|
<hr WIDTH="100%"><b><font color="#CC0000">Local: </font></b><a href="#templates">Templates</a>
|
|
-
|
|
<a href="#functors">Functors</a> -
|
|
<a href="#STL">STL Library</a> - <a href="#random">Random
|
|
numbers</a> - <a href="#notations">EO programming style</a> - <a href="#memory">Memory
|
|
management</a>
|
|
<br>
|
|
<hr WIDTH="100%">
|
|
<center>
|
|
<h1>
|
|
<font color="#FF0000">EO Programming guide</font></h1></center>
|
|
|
|
<hr WIDTH="100%">
|
|
<br><a NAME="templates"></a><b><font color="#000099"><font size=+1>Templates</font></font></b>
|
|
<p>Most EO code is written using templates. This allows to write generic
|
|
code, i.e. involving a class which doesn't have to be known when writing
|
|
the code -- but only when compiling it. In some sense this is similar to
|
|
naming variables in algebra: you can write a lot of equations involving
|
|
some variable $x$ without knowing even it if will be an integer or a float
|
|
(or a matrix or ...). The main basic type that is templatized in EO is
|
|
the fitness: an EO object is some object which has a fitness of some type
|
|
F that can be anything. The definition for that is (see <font face="Arial,Helvetica"><a href="../../doc/html/_e_o_8h-source.html">EO.h</a></font>)
|
|
<p><b><tt><font color="#999900">template<class F> class EO</font></tt></b>
|
|
<p>The idea is that, later in your code, you can define a class as follows
|
|
(see for instance <a href="../../doc/html/eoOneMax.html">eoOneMax.h</a> - or check <a href="eoLesson5.html">Lesson 5</a> for more details).
|
|
<p><b><tt><font color="#999900">template<class F> class eoOneMax : public
|
|
EO<F></font></tt></b>
|
|
<br><b><tt><font color="#999900">{ ... code for eoOneMax };</font></tt></b>
|
|
<p>and then use it in your application as
|
|
<p><b><tt><font color="#999900">eoOneMax<double> myeoBit;</font></tt></b>
|
|
<p>declares an object of type eoOneMax which has as fitness a double.
|
|
<p>Whereas the <b><font color="#FF6600">advantages</font></b>
|
|
are obvious (writing generic reusable code instead
|
|
of having to rewrite the same pieces of code for different types), there
|
|
are some <b><font color="#FF6600">drawbacks</font></b>:
|
|
namely, it makes some of the compiler error messages
|
|
hard to understand; and it forbids the compilation of most parts of EO
|
|
into an object library file, as the actual types are not known in advance.
|
|
<p>
|
|
<hr WIDTH="100%">
|
|
<br><a NAME="functors"></a><b><font color="#000099"><font size=+1>Functors</font></font></b>
|
|
<p>Though EO is a library, it contains almost no functions per se!
|
|
<br>EO mainly contains functors, that are objects which have a method called
|
|
<b><tt><font color="#FF6600">operator()</font></tt></b>.
|
|
Such objects are used as if they were functions, but the big differences
|
|
are that
|
|
<ul>
|
|
<li>
|
|
functors are functions with private data</li>
|
|
|
|
<li>
|
|
you can have different functors objects of the same class, i.e. you can
|
|
use at the same time the same functionality with different parameters</li>
|
|
|
|
<li>
|
|
you can have a hierarchy of functors objects, which means that you have
|
|
a hierarchy of functions with defaults behaviors and specialized sub-functions</li>
|
|
|
|
<li>
|
|
...</li>
|
|
</ul>
|
|
Functors are so intimately linked to EO that a base class (<b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_functor_base.html">eoFunctorBase</a></font></font></b>)
|
|
has been designed to hold all functors. This base class is itself divided
|
|
into three derived class. These classes tell you immediately what kind
|
|
of arguments the <b><tt><font color="#993300">operator()</font></tt></b>
|
|
method requires and what kind of result it produces. See <a href="#notations">EO
|
|
conventions</a>, and the <b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_functor_base.html">inheritance
|
|
diagram of class eoFunctorBase</a>. </font></font></b> Also note that
|
|
if you create new functors, you should also derive from one of these classes,
|
|
as it is mandatory if you later use the EO <a href="#memory">memory management
|
|
mechanism</a>.
|
|
<br>For a more complete introduction to functors, with detailed discussion,
|
|
go to the <a href="http://www.sgi.com/tech/stl/functors.html">STL documentation</a>
|
|
- as STL also heavily relies on functors, and the eoFunctorBase paradigm
|
|
is borrowed from there.
|
|
<p><b><font color="#FF0000">Functors:</font><font color="#000099"> Example:</font></b>
|
|
<p>The following is a basic example of how to program and use a functor
|
|
object: First code the class:
|
|
<p><b><tt><font color="#993300">class MyFunctor</font></tt></b>
|
|
<br><b><tt><font color="#993300">{ ...</font></tt></b>
|
|
<br><b><tt><font color="#993300"> void operator()(ArgType
|
|
arg)</font></tt></b>
|
|
<br><b><tt><font color="#993300"> {</font></tt></b>
|
|
<br><tt><font color="#993300">
|
|
// do what you have to do</font></tt>
|
|
<br><b><tt><font color="#993300"> }</font></tt></b>
|
|
<br><tt><font color="#993300"><b>}; </b>// end of class declaration</font></tt>
|
|
<p>Then use it later in the code :
|
|
<p><b><tt><font color="#993300">ArgType myArgument;</font></tt></b>
|
|
<br><tt><font color="#993300"><b>MyFunctor myFunctorInstance; </b>
|
|
// myFunctorInstance is an object of class MyFUnctor ...</font></tt>
|
|
<br><tt><font color="#993300"><b>myFunctorInstance(myArgument);</b>
|
|
// calls operator() of myFunctorInstance acting on myArgument ...</font></tt>
|
|
<br>
|
|
<p><b><font color="#FF0000">Functors:</font><font color="#000099"> The
|
|
three basic classes:</font></b>
|
|
<p><font color="#000000">Direct sub-classes of the root class , three classes
|
|
are defined to differentiate functors by the number of argument required
|
|
by their </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">.
|
|
These classes are templatized by the types of its arguments, and by its
|
|
return type. Hence,</font>
|
|
<br><font color="#000000">from the inheritance diagram of any functor class
|
|
in EO, you can immediately deduce the interface of their </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">
|
|
method.</font>
|
|
<br>
|
|
<ul>
|
|
<li>
|
|
<b><tt><font color="#FF6600">eoF</font></tt></b><font color="#000000">
|
|
is for arity-zero functors, i.e. their </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">
|
|
method does not require any argument. It has a single template parameter,
|
|
the return type of the </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">
|
|
method. For instance, </font> <b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_monitor.html">eoMonitor</a></font></font></b> <font color="#000000">
|
|
are </font><b><tt><font color="#FF6600">eoF</font></tt></b><font color="#000000">'s
|
|
that return an </font><b><tt><font color="#993300">eoMonitor &</font></tt></b><font color="#000000">.</font></li>
|
|
|
|
<li>
|
|
<b><tt><font color="#FF6600">eoUF</font></tt></b><font color="#000000">
|
|
is for unary functors, i.e. their </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">
|
|
method requires one argument. It has two template parameters, the type
|
|
of the argument and the return type of the </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">
|
|
method. For instance, </font> <b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_mon_op.html">eoMonOp</a></font></font></b>'s<font color="#000000">
|
|
are </font><b><tt><font color="#FF6600">eoUF</font></tt></b><font color="#000000">'s
|
|
that take as argument an </font><b><tt><font color="#993300">EOT &</font></tt></b><font color="#000000">
|
|
and return </font><b><tt><font color="#993300">void</font></tt></b><font color="#000000">
|
|
.</font></li>
|
|
|
|
<li>
|
|
<b><tt><font color="#FF6600">eoBF</font></tt></b><font color="#000000">
|
|
is for binary functors, i.e. their </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">
|
|
method requires two arguments. It has three template parameters, the types
|
|
of the arguments and the return type of the </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">
|
|
method. For instance, </font> <b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_bin_op.html">eoBinOp</a></font></font></b>'s<font color="#000000">
|
|
are </font><b><tt><font color="#FF6600">eoBF</font></tt></b><font color="#000000">'s
|
|
that take as arguments a </font><b><tt><font color="#993300">const EOT
|
|
&</font></tt></b><font color="#000000"> and an </font><b><tt><font color="#993300">EOT
|
|
&</font></tt></b><font color="#000000">, and return </font><b><tt><font color="#993300">void</font></tt></b><font color="#000000">
|
|
.</font></li>
|
|
</ul>
|
|
<font color="#000000">Now go back to the </font><b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_functor_base.html">inheritance
|
|
diagram of class eoFunctorBase</a></font></font></b><font color="#000000">,
|
|
and guess the interface for all functors!</font>
|
|
<p><b><font color="#FF0000">Note</font></b><font color="#000000">: for
|
|
obvious simplicity reasons, we very often omit the reference to the </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">,
|
|
e.g. when we say above:</font>
|
|
<ul>
|
|
<li>
|
|
<b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_mon_op.html">eoMonOp</a></font></font></b>'s<font color="#000000">
|
|
are </font><b><tt><font color="#FF6600">eoUF</font></tt></b><font color="#000000">'s
|
|
that take as argument an </font><b><tt><font color="#993300">EOT &</font></tt></b><font color="#000000">
|
|
and return </font><b><tt><font color="#993300">void</font></tt></b></li>
|
|
</ul>
|
|
<font color="#000000">it actually means</font>
|
|
<ul>
|
|
<li>
|
|
<b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_mon_op.html">eoMonOp</a></font></font></b>'s<font color="#000000">
|
|
are </font><b><tt><font color="#FF6600">eoUF</font></tt></b><font color="#000000">'s,
|
|
their </font><b><tt><font color="#993300">operator()</font></tt></b><font color="#000000">
|
|
method takes as argument an </font><b><tt><font color="#993300">EOT &</font></tt></b><font color="#000000">
|
|
and returns </font><b><tt><font color="#993300">void</font></tt></b><font color="#000000">.</font></li>
|
|
</ul>
|
|
|
|
<p><br>
|
|
<hr WIDTH="100%">
|
|
<br><a NAME="STL"></a><b><font color="#000099"><font size=+1>A very brief
|
|
introduction to STL</font></font></b>
|
|
<p>All EO heavily relies on <b><font color="#FF6600">STL, the Standard
|
|
Template Library</font></b>.
|
|
<br>But <font color="#FF6600">you don't have to know more than a few words
|
|
of STL</font> to use EO (like with "hello", "please" and "goodbye" you
|
|
can survive in a foreign country :-) and even to contribute to new EO features.
|
|
Moreover, while browsing through EO code, you will gradually learn how
|
|
to use STL, especially if you check at the <a href="http://www.sgi.com/tech/stl/">SGI
|
|
STL Web site</a> from time to time, where you can not only download STL,
|
|
but also browse in the Programmer's guide for isntance from the <a href="http://www.sgi.com/tech/stl/table_of_contents.html">Table
|
|
of Content</a>.
|
|
<p>Anyway, you will only find here, in EO tutorial, the basics of STL that
|
|
you will need to understand most of EO code - and to guess what the parts
|
|
you don't understand are actually doing. Don't worry, <b><font color="#FF6600">I
|
|
</font></b>don't
|
|
understand everything :-)
|
|
<p>STL provides the user with <b><font color="#FF6600">container</font></b>s,
|
|
<b><font color="#FF6600">iterators</font></b>
|
|
and <b><font color="#FF6600">algorithms</font></b>. And you can access
|
|
(almost) all containers content using (almost) all iterators, or apply
|
|
(almost) all algorithms on (almost) all containers (of course the tricky
|
|
part is to instanciate the "almost" in the previous sentence :-)
|
|
<p><b><font color="#FF0000">STL: </font><font color="#000099">Containers</font></b>
|
|
<br>Containers are high level data types used to hold simpler data - the
|
|
most widely used example of a container is the <b><font color="#FF6600">vector</font></b>
|
|
construct.
|
|
<br>The use of STL containers relieve the user from memory management.
|
|
<ul>
|
|
<li>
|
|
<b><tt><font color="#000099"><font size=+1>vector </font></font></tt></b><font color="#000000">The
|
|
most widely used container is a one-dimensional array of items.</font></li>
|
|
|
|
<br><font color="#000000">Data manipulation: suppose </font><font color="#FF6600">v
|
|
is an STL </font><b><tt><font color="#993300">vector<AtomType></font></tt></b><font color="#000000">.
|
|
Then</font>
|
|
<br><b><tt><font color="#993300">v[i]</font></tt></b><font color="#000000">
|
|
is the ith element of v, as in standard C arrays</font>
|
|
<br><b><tt><font color="#993300">v.size()</font></tt></b><font color="#000000">
|
|
is the number of elements of v</font>
|
|
<br><b><tt><font color="#993300">v.push_back(atom)</font></tt></b><font color="#000000">
|
|
appends the </font><b><tt><font color="#993300">atom</font></tt></b><font color="#000000">
|
|
at end of </font><b><tt><font color="#993300">v</font></tt></b><font color="#000000">,
|
|
provided of course that </font><b><tt><font color="#993300">atom</font></tt></b><font color="#000000">
|
|
is of type </font><b><tt><font color="#993300">AtomType</font></tt></b><font color="#000000">,
|
|
the size is automatically increased...</font>
|
|
<br><font color="#000000">blabla insert, erase, ...</font>
|
|
<li>
|
|
<b><tt><font color="#000099"><font size=+1>list</font></font></tt></b><font color="#000000">
|
|
STL provides different types of list. The one used in EO is the simple
|
|
linked list named ... </font><b><tt><font color="#993300">list</font></tt></b><font color="#000000">.
|
|
As far as the user is concerned, simple lists are very similar to vectors,
|
|
and the data manipulation listed above for vectors can be applied to list.</font></li>
|
|
|
|
<li>
|
|
<b><tt><font color="#000099"><font size=+1>pair</font></font></tt></b></li>
|
|
|
|
<br><font color="#000000">This simple container allows you to hold two
|
|
data types together. It is very handy for temporary data handling. Assuming
|
|
p is a </font><b><tt><font color="#993300">pair<AtomType1, AtomType2></font></tt></b><font color="#000000">,
|
|
</font><b><tt><font color="#993300">p.first</font></tt></b><font color="#000000">
|
|
and </font><b><tt><font color="#993300">p.second</font></tt></b><font color="#000000">
|
|
refer to the encapsulated data, of respective types </font><b><tt><font color="#993300">AtomType1</font></tt></b><font color="#000000">
|
|
and
|
|
</font><b><tt><font color="#993300">AtomType2</font></tt></b>
|
|
<li>
|
|
<b><tt><font color="#000099"><font size=+1>Blabla</font></font></tt></b></li>
|
|
</ul>
|
|
There are many other types of containers that are not used in EO and that
|
|
we will not present here.
|
|
<p><b><font color="#FF0000">STL: </font><font color="#000099">Iterators</font></b>
|
|
<br>Iterators are accessors to the containers contents that provide unified
|
|
access to different containers. They are very similar to pointers, i.e.
|
|
you can increment them, compare them with one another, etc
|
|
<p>Some very useful iterators for vectors and lists are <b><font color="#FF6600">begin()</font></b>
|
|
and e<b><font color="#FF6600">nd()</font></b>, that refer to the first
|
|
and after-last items of a container. They allow loops to sweep all items
|
|
contained in a container as follows:
|
|
<br><b><tt><font color="#993300">STLcontainer myContain;</font></tt></b>
|
|
<br><b><tt><font color="#993300">STLcontainer::iterator it;</font></tt></b>
|
|
<br><b><tt><font color="#993300">for (it=myContain.begin(); it!=myContain.end();
|
|
it++)</font></tt></b>
|
|
<br><b><tt><font color="#993300">{</font></tt></b>
|
|
<br><tt><font color="#993300">// do what you have to do to
|
|
<b>(*it)</b>
|
|
the current item in the container</font></tt>
|
|
<br><b><tt><font color="#993300">}</font></tt></b>
|
|
<p><b><font color="#FF0000">STL: </font><font color="#000099">Algorithms</font></b>
|
|
<br>Algorithms are functions acting on containers - the most widely used
|
|
example of a STL algorithm are the different <b><font color="#FF6600">sort</font></b>ing
|
|
algorithms.
|
|
<ul>
|
|
<li>
|
|
<b><tt><font color="#993300">sort, nth_element</font></tt></b>, are sorting
|
|
algorithms used in EO</li>
|
|
|
|
<li>
|
|
<b><tt><font color="#993300">copy</font></tt></b> is used to copy a range
|
|
of data designated by iterators</li>
|
|
|
|
<li>
|
|
<b><tt><font color="#993300">apply</font></tt></b> is used to perform the
|
|
same operation to many items designated by a range of iterators</li>
|
|
|
|
<li>
|
|
Blabla - help wanted thanks...</li>
|
|
</ul>
|
|
<b><font color="#FF0000">STL: </font><font color="#000099">Advantages</font></b>
|
|
<br>The main and <b><font color="#FF6600">huge advantage</font></b> of
|
|
using STL is that it handles (almost all) memory mangement automatically.
|
|
You can use any STL container the same way you would use a scalar basic
|
|
C++ type. And it does it in a (supposededly) optimized way. Of course,
|
|
the user is also responsible for performances: for instance, the insert()
|
|
method will take more time for vectors than for linked lists, while on
|
|
the opposite, the operator[] accessor will be faster for vectors. But both
|
|
will work anyway.
|
|
<p><b><font color="#FF0000">STL: </font><font color="#000099">Drawbacks</font></b>
|
|
<br>The main drawback I see in using STL is that it makes it
|
|
<b><font color="#FF6600">difficult
|
|
to use a debugger </font></b>normally: whereas access to data is made simple
|
|
to the programmer, data structures are actually so complex, and debuggers
|
|
so willing to display everything that you get lines of template instantiation
|
|
when asking your debugger what is inside some container! <br>
|
|
However, here is a trick (thanks to Arnaud Quirin!) to actually print what is inside an STL vector with gdb (but it doesn't really work with complex structures like EO genotypes :-( :<br/>
|
|
<b><tt>(gdb) <font color="#993300">print (*(&v))[i]<br/>
|
|
$1 = (const double &) @0x934cad0: 0.69543264131061733<br/></font></tt></b>
|
|
<!-- For instance I
|
|
could never visualize some
|
|
<b><tt><font color="#993300">v[i]</font></tt></b>
|
|
with <b><tt><font color="#FF6600">gbd</font></tt></b>, <b><tt><font color="#993300">v</font></tt></b>
|
|
being an STL vector! -->
|
|
<p>
|
|
<hr WIDTH="100%">
|
|
<br><a NAME="random"></a><b><font color="#000099"><font size=+1>Random
|
|
numbers</font></font></b>
|
|
<p>Evolutionary Algorithms make intensive use of random numbers. Random
|
|
numbers are simulated in computers by using <font color="#FF6600">pseudo-random</font>
|
|
number generators (RNGs for short), i.e. functions that return series of
|
|
numbers who look random (w.r.t. some statistical criteria).
|
|
<p>To make sure the random number generator is as good as possible, and
|
|
to ensure reproducibility of the results across different platforms, EO
|
|
has its own RNG, the ``<font color="#FF6600">Mersenne Twister</font>''
|
|
random number generator MT19937 (thanks to <font color="#FF0000">Takuji
|
|
Nishimura</font>, see <font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/eo_r_n_g_8h-source.html">eoRNG.h</a></font></font>
|
|
comments).
|
|
<p>Though you can define and use as many RNGs as you wish in EO, the library
|
|
also provides you with a global RNG termed <b><tt><font color="#993300">eo::rng</font></tt></b>.
|
|
Using that single RNG in all calls to random numbers allows one to be able
|
|
to <b><font color="#FF6600">reproduce a given run</font></b>:
|
|
<ul>
|
|
<li>
|
|
as strange as it seems for a random algorithm, it is mandatory for debugging
|
|
purposes</li>
|
|
|
|
<li>
|
|
random numbers are computed starting from a seed - starting from the same
|
|
seed will lead to the same series of pseudo-random numbers, and hence to
|
|
the same results of the algorithms. All examples in this tutorial will
|
|
use the RNG seeding procedure, see e.g. in <a href="FirstBitGA.html#random">Lesson1</a>.</li>
|
|
|
|
<li>
|
|
to simulate "true" random runs, you can just seed the RNG with a machine-clock
|
|
related number, e.g. calling time(0), as done for instance in <a href="SecondBitEA.html#random">Lesson3</a>
|
|
(and after).</li>
|
|
</ul>
|
|
As RNGs produce, by definition, integers that are uniformly distributed
|
|
between 0 and some maximal number, EO provides you with random numbers
|
|
following <b><font color="#FF6600">different probability distribution</font></b>
|
|
(e.g. floating point following <font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_rng.html#a8">normal
|
|
distribution</a></font></font>). See the <a href="../../doc/html/classeo_rng.html">complete
|
|
list of RNG primitives</a>.
|
|
<p>EO also provides <a href="../../doc/html/rnd__generators_8h-source.html">random_generators</a>
|
|
that can be used in STL call to generate series of random numbers, as in
|
|
<a href="eoInit.html">eoPop
|
|
initializers</a>.
|
|
<p><b><font color="#FF0000">Note</font></b>: the <b><tt><font color="#993300">eo::</font></tt></b>
|
|
prefix indicates that it is in a separate C++ namespace, to avoid collision
|
|
with possible variables that would also be named rng in some other library.
|
|
As early versions of EO (<= 9.1) did not use a separate namespace
|
|
for rng, the compiler directive using eo::rng in eoRNG.h allows you to
|
|
use the name rng without the <b><tt><font color="#993300">eo::</font></tt></b>
|
|
prefix. However, the notation <b><tt><font color="#993300">eo::rng</font></tt></b>
|
|
should be preferred and might become mandatory some day.
|
|
<br>
|
|
<hr WIDTH="100%">
|
|
<br><a NAME="notations"></a><b><font color="#000099"><font size=+1>EO conventions
|
|
and naming style</font></font></b>
|
|
<p>A few naming conventions should help you to navigate more easily through
|
|
EO:
|
|
<ul>
|
|
<li>
|
|
The name of local variables should start with a lower case letter. Capital
|
|
letters should be used rather than underscore to separate words in names
|
|
(e.g. <b><tt><font color="#FF6600">popSize</font></tt></b> rather than
|
|
<b><tt><font color="#993300">pop_size</font></tt></b>).</li>
|
|
|
|
<li>
|
|
The name of the arguments to a function should start with an underscore,
|
|
e.g.</li>
|
|
|
|
<br><b><tt> <font color="#993300">void
|
|
myfunction(unsigned </font><font color="#FF6600">_popSize</font><font color="#993300">){...}</font></tt></b>
|
|
<li>
|
|
The initialization parameters of constructors should be named from the
|
|
names of the variables they are used to initialize, e.g.</li>
|
|
|
|
<br>
|
|
<p>
|
|
<br>
|
|
<br>
|
|
<p><b><tt><font color="#993300">class eoMyClass</font></tt></b>
|
|
<br><b><tt><font color="#993300">{</font></tt></b>
|
|
<br><b><tt><font color="#993300">public:</font></tt></b>
|
|
<br><b><tt><font color="#993300"> eoMyClass(unsigned _popSize):</font><font color="#FF6600">popSize(_popSize)</font><font color="#993300">{...}</font></tt></b>
|
|
<br><b><tt><font color="#993300"> ...</font></tt></b>
|
|
<br><b><tt><font color="#993300">private:</font></tt></b>
|
|
<br><b><tt><font color="#993300"> unsigned popSize;</font></tt></b>
|
|
<br><b><tt><font color="#993300">};</font></tt></b>
|
|
<li>
|
|
The names of classes should start with eo + an Uppercase letter (as <b><tt><font color="#993300">eoMyClass</font></tt></b>
|
|
above).</li>
|
|
|
|
<li>
|
|
The name of the EO template should be EOT. This allows quick understanding
|
|
of the inheritance diagrams for <a href="#functors">functors</a>. and immediate
|
|
perception of the arguments and return types of the functors oeprator()
|
|
method (as in <b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_mon_op.html">eoMonOp</a></font></font></b>
|
|
or <b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_bin_op.html">eoBinOp</a></font></font></b>).</li>
|
|
|
|
<br>
|
|
<li>
|
|
Blabla</li>
|
|
</ul>
|
|
|
|
<hr WIDTH="100%">
|
|
<br><a NAME="memory"></a><b><font color="#000099"><font size=+1>EO memory
|
|
management</font></font></b>
|
|
<p>Most of EO constructs are based on the <b><font color="#FF6600">encapsulation</font></b>
|
|
of objects into other objects, and the embedded objects are passed through
|
|
the constructor of the embedding object.
|
|
<br>For instance, the construction of an algorithm requires a breeder (plus
|
|
many other things of course), the construction of a breeder usually requires
|
|
a selector, and in turn the construction of a selector requires some parameters.
|
|
This gives something resembling the following
|
|
<p><b><tt><font color="#993300">eoTournamentSelection<EOT> select(tSize);</font></tt></b>
|
|
<br><b><tt><font color="#993300">eoBreeder<EOT> breed(select);</font></tt></b>
|
|
<br><b><tt><font color="#993300">eoEasyAlgo<EOT> algo( ..., breed, ...);</font></tt></b>
|
|
<p>Such a practice is no problem when doing <b><font color="#FF6600">everything
|
|
in a (large!) main function</font></b>: all objects are local to that function,
|
|
but when the end of the function is also the end of the program. For instance,
|
|
all programs in <a href="eoLesson1.html">Lesson1</a>, <a href="eoLesson2.html">Lesson2</a>
|
|
and <a href="eoLesson3.html">Lesson3</a> of this tutorial are built that
|
|
way.
|
|
<p>It is however a big problem when you want to outsource some code in
|
|
other functions: indeed, the above sequence create objects that <b><font color="#FF6600">dissapear</font></b>
|
|
when exiting the function, and thus cannot be used outside their defining
|
|
function.
|
|
<p>The solution is of course to use <b><font color="#FF6600">pointers</font></b>,
|
|
which gives something like
|
|
<p><b><tt><font color="#993300">eoTournamentSelection<EOT> *ptSelect
|
|
= new eoTournamentSelection<EOT>(tSize);</font></tt></b>
|
|
<br><b><tt><font color="#993300">eoBreeder<EOT> *ptBreed = new eoBreeder<EOT>(*ptSselect);</font></tt></b>
|
|
<br><b><tt><font color="#993300">eoEasyAlgo<EOT> *ptAlgo = new eoEasyAlgo<EOT>(
|
|
..., *ptBreed, ...);</font></tt></b>
|
|
<p>and you can then use the dynamically allocated objects anywhere. But
|
|
the trouble with such a construct is that after exiting the function where
|
|
such objects are defined, <b><font color="#FF6600">you will never be able
|
|
to free</font></b> this allocated memory, should you not need the objects
|
|
any nore. Whereas this is not in general a big problem (except of being
|
|
a very bad practice that will make you a very naughty programmer :-), it
|
|
will prevent any re-entrance of the resulting code, and for instance you
|
|
will not be able to use an evolutionary algorithm within another loop of
|
|
some outside code.
|
|
<p>The solution in EO us to use an <b><tt><font color="#993300"><font size=+1><a href="../../doc/html/classeo_functor_store.html">eoFunctorStore</a></font></font></tt></b>
|
|
object to store such nowhere-belonging pointers: whenever you allocate
|
|
such a thing, store it into an eoState : deleting that state will delete
|
|
all the stored pointers - one eoState is thus the only object you have
|
|
to care of.
|
|
<p>The above pointer allocation sequence thus become
|
|
<p><b><tt><font color="#993300">eoTournamentSelection<EOT> *ptSelect
|
|
= new eoTournamentSelection<EOT>(tSize);</font></tt></b>
|
|
<br><b><tt><font color="#993300">state.storeFunctor(ptSelect);</font></tt></b>
|
|
<br><b><tt><font color="#993300">eoBreeder<EOT> *ptBreed = new eoBreeder<EOT>(*ptSelect);</font></tt></b>
|
|
<br><b><tt><font color="#993300">state.storeFunctor(ptBreed);</font></tt></b>
|
|
<br><b><tt><font color="#993300">eoEasyAlgo<EOT> *ptAlgo = new eoEasyAlgo<EOT>(
|
|
..., *ptBreed, ...);</font></tt></b>
|
|
<br><b><tt><font color="#993300">state.storeFunctor(ptAlgo);</font></tt></b>
|
|
<p>or, even more quickly (though less readably)
|
|
<p><b><tt><font color="#993300">eoTournamentSelection<EOT> *ptSelect
|
|
=</font></tt></b>
|
|
<br><b><tt><font color="#993300">
|
|
state.storeFunctor(new eoTournamentSelection<EOT>(tSize));</font></tt></b>
|
|
<br><b><tt><font color="#993300">eoBreeder<EOT> *ptBreed =</font></tt></b>
|
|
<br><b><tt><font color="#993300">
|
|
state.storeFunctor(new eoBreeder<EOT>(*ptSelect));</font></tt></b>
|
|
<br><b><tt><font color="#993300">eoEasyAlgo<EOT> *ptAlgo =</font></tt></b>
|
|
<br><b><tt><font color="#993300">
|
|
state.storeFunctor(new eoEasyAlgo<EOT>( ..., *ptBreed, ...));</font></tt></b>
|
|
<p>In both the above code, state is an <b><tt><font color="#993300"><font size=+1>eoFunctorStore</font></font></tt></b>
|
|
that is of course <b><font color="#FF6600">passed from outside the function</font></b>
|
|
- and it's called state because in most cases it will actually be an eoState.
|
|
As its name says, an <b><tt><font color="#993300"><font size=+1>eoFunctorStore</font></font></tt></b>
|
|
can store any object that is an (derives from) <b><tt><font size=+1><a href="../../doc/html/classeo_functor_base.html">eoFunctorBase</a></font></tt></b>
|
|
- hence all objects in EO that are used as functors should derive from
|
|
either <a href="#functors">eoF, eoUF or eBF</a>.
|
|
<p>Examples of such constructs are shown in the make_xxx files described
|
|
in <a href="eoLesson4.html">Lesson4</a>.
|
|
<br>
|
|
<hr WIDTH="100%"><b><font color="#CC0000">Local: </font></b><a href="#templates">Templates</a>
|
|
-
|
|
<a href="#functors">Functors</a> -
|
|
<a href="#STL">STL Library</a> - <a href="#random">Random
|
|
numbers</a> - <a href="#notations">EO programming style</a> - <a href="#memory">Memory
|
|
management</a>
|
|
<br>
|
|
<hr WIDTH="100%">
|
|
<br><b><font color="#CC0000">General: </font></b><a href="eoTutorial.html">Tutorial
|
|
main page </a>- <a href="eoTopDown.html">Algorithm-Based</a> - <a href="eoBottomUp.html">Component-Based</a>
|
|
- <a href="eoProgramming.html">Programming hints</a> - <font face="Arial,Helvetica"><a href="../../doc/html/index.html">EO
|
|
documentation</a></font>
|
|
<br>
|
|
<hr>
|
|
<br><a href="mailto:Marc.Schoenauer@inria.fr">Marc Schoenauer</a>
|
|
</body>
|
|
</html>
|