eoprogramming.html

这是linux下的进化计算的源代码。 === === === === === === === === === === === ===== check latest news at http:

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 almost
<b><font color="#FF6600">impossible
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! 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 (&lt;= 9.1)&nbsp; 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <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>&nbsp;
<p>&nbsp;
<br>&nbsp;
<br>&nbsp;
<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">&nbsp; eoMyClass(unsigned _popSize):</font><font color="#FF6600">popSize(_popSize)</font><font color="#993300">{...}</font></tt></b>
<br><b><tt><font color="#993300">&nbsp;&nbsp; ...</font></tt></b>
<br><b><tt><font color="#993300">private:</font></tt></b>
<br><b><tt><font color="#993300">&nbsp;&nbsp; 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&nbsp; <b><font face="Arial,Helvetica"><font size=+1><a href="../../doc/html/classeo_bin_op.html">eoBinOp</a></font></font></b>).</li>

<br>&nbsp;
<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&lt;EOT>&nbsp; select(tSize);</font></tt></b>
<br><b><tt><font color="#993300">eoBreeder&lt;EOT> breed(select);</font></tt></b>
<br><b><tt><font color="#993300">eoEasyAlgo&lt;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&lt;EOT>&nbsp; *ptSelect
= new eoTournamentSelection&lt;EOT>(tSize);</font></tt></b>
<br><b><tt><font color="#993300">eoBreeder&lt;EOT> *ptBreed = new eoBreeder&lt;EOT>(*ptSselect);</font></tt></b>
<br><b><tt><font color="#993300">eoEasyAlgo&lt;EOT> *ptAlgo = new eoEasyAlgo&lt;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&lt;EOT>&nbsp; *ptSelect
= new eoTournamentSelection&lt;EOT>(tSize);</font></tt></b>
<br><b><tt><font color="#993300">state.storeFunctor(ptSelect);</font></tt></b>
<br><b><tt><font color="#993300">eoBreeder&lt;EOT> *ptBreed = new eoBreeder&lt;EOT>(*ptSelect);</font></tt></b>
<br><b><tt><font color="#993300">state.storeFunctor(ptBreed);</font></tt></b>
<br><b><tt><font color="#993300">eoEasyAlgo&lt;EOT> *ptAlgo = new eoEasyAlgo&lt;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&lt;EOT>&nbsp; *ptSelect
=</font></tt></b>
<br><b><tt><font color="#993300">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
state.storeFunctor(new eoTournamentSelection&lt;EOT>(tSize));</font></tt></b>
<br><b><tt><font color="#993300">eoBreeder&lt;EOT> *ptBreed =</font></tt></b>
<br><b><tt><font color="#993300">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
state.storeFunctor(new eoBreeder&lt;EOT>(*ptSelect));</font></tt></b>
<br><b><tt><font color="#993300">eoEasyAlgo&lt;EOT> *ptAlgo =</font></tt></b>
<br><b><tt><font color="#993300">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
state.storeFunctor(new eoEasyAlgo&lt;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>&nbsp; - <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:[e-mail]">Marc Schoenauer</a>
</body>
</html>