diff --git a/eo/tutorial/html/eoProgramming.html b/eo/tutorial/html/eoProgramming.html index 97627762..2951fde8 100644 --- a/eo/tutorial/html/eoProgramming.html +++ b/eo/tutorial/html/eoProgramming.html @@ -2,42 +2,43 @@ - + EO Programming guide -Tutorial main page - -Algorithm-Based -page - Component-Based - Programming -hints - EO +General: Tutorial +main page - +Algorithm-Based - Component-Based +- Programming hints - EO documentation
-
+
Local: Templates +- +Functors - +STL Library - Random +numbers - EO programming style +
+

EO Programming guide

-Templates, -Functors, -STL -Library, random numbers, EO programming style! -
+

Templates -
Most EO code is written using templates. This allows to write generic +

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 (seeEO.h) -

template<F> class EO +F that can be anything. The definition for that is (see EO.h) +

template<F> class EO

The idea is that, later in your code, you can declare for instance as in FirstBitGA.cpp -

typedef eoBin<double> -Genotype; -

meaning that in that file, you will manipulate as Genotype -objects that are EO objects whosefitness +

typedef eoBin<double> Genotype; +

meaning that in that file, you will manipulate as Genotype +objects that are EO objects whose fitness is a double.

Whereas the advantages are obvious (writing generic reusable code instead of having to rewrite the same pieces of code for different types), there @@ -47,10 +48,10 @@ into an object library file, as the actual types are not known in advance.


Functors -

Though EO is a library, it contains almost no functions! -
EO only contains functors, that are objects which have a method called -operator(). -Such objects are used  as if they were a function, but the big differences +

Though EO is a library, it contains almost no functions per se! +
EO mainly contains functors, that are objects which have a method called +operator(). +Such objects are used  as if they were functions, but the big differences are that

-Functors are so intimately linked to EO that a base class (eoFunctorBase) +Functors are so intimately linked to EO that a base class (eoFunctorBase) 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 operator() method requires -and what kind of result it produces. See EO conventions, -and -the inheritance diagram of class -eoFunctorBase. -

Example -

A good example is given by the eoEvalFuncPtr -class -

class MyClass -
{ ... -
    void operator()(ArgType -arg) -
       { +of arguments the operator() +method requires and what kind of result it produces. See EO +conventions, and the inheritance +diagram of class eoFunctorBase. +

Functors: Example: +

The following is a basic example of how to program and use a functor +object: First code the class: +

class MyClass +
{ ... +
    void operator()(ArgType +arg) +
       {
            // do what you have to do -
       } -
}; // end of class declaration -

is used  later in the code in something  like +
       } +
}; // end of class declaration +

Then use it  later in the code : +

ArgType myArgument; +
MyClass myObject;    +// myObject is an object of class MyClass ... +
myObject(myArgument);  // calls +operator() of myObject acting on myArgument ...
  -

ArgType myArgument; -
MyClass myObject;    // myObject -is an object of class MyClass ... -
myObject(myArgument);  // calls method -operator() of object myObject with argument myArgument ... +

Functors: The +three basic classes: +

Direct sub-classes of the root class , three classes +are defined to differentiate functors by the number of argument required +by their operator(). +These classes are templatized by the types of its arguments, and by its +return type. Hence, +
from the inheritance diagram of any functor class +in EO, you can immediately deduce the interface of their operator() +method.
  -
  -
  -

-Why not plain C functions?

-Consider for instance variation operators. Of course, we could declare -them as function acting on some objects. -

Blabla -

+

+Now go back to the inheritance +diagram of class eoFunctorBase, +and guess the interface for all functors! +

Note: for +obvious simplicity reasons, we very often omit the reference to the operator(), +e.g. when we say above: +

+it actually means + + +



A very brief introduction to STL @@ -115,10 +174,12 @@ can survive in a foreign country :-) and even to contribute to new EO features. most of EO code - and to guess what the parts you don't understand are actually doing. Don't worry, I don't understand everything :-) -

STL provides the user with container -and algorithms. And you can apply (almost) -all algorithms on (almost) all containers. -

Containers +

STL provides the user with containers, +iterators +and algorithms. And you can access +(almost) all containers content using (almost) all iterators, or apply +(almost) all algorithms on (almost) all containers. +

STL: Containers
Containers are high level data types used to hold simpler data - the most widely used example of a container is the vector construct. @@ -129,40 +190,89 @@ construct. most widely used container is a one-dimensional array of items.
Data manipulation: suppose v -is an STL vector<AtomType>. +is an STL vector<AtomType>. Then -
v[i] +
v[i] is the ith element of v, as in standard C arrays -
v.size() +
v.size() is the number of elements of v -
v.push_back(atom) -appends the atom -at end of v, -provided of course that atom -is of type AtomType -
blabla +
v.push_back(atom) +appends the atom +at end of v, +provided of course that atom +is of type AtomType, +the size is automatically increased... +
blabla insert, erase, ... +

  • +list +STL provides different types of list. The one used in EO is the simple +linked list named ... list. +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.
    • +
  • pair

    • This simple container allows you to hold two data types together. It is very handy for temporary data handling. Assuming -p is a pair<AtomType1, -AtomType2>, -
    p.first() -and p.second()  -refer to the encapsulated data, of respective types AtomType1and -AtomType2. +p is a     pair<AtomType1, AtomType2>, +p.first() +and p.second()  +refer to the encapsulated data, of respective types AtomType1 +and +AtomType2
  • Blabla
    • There are many other types of containers that are not used in EO and that we will not present here. -

    STL Algorithms +

    STL: Iterators +
    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 +

    Some very useful iterators for vectors and lists are begin() +and end(), 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: +
    STLcontainer myContain; +
    STLcontainer::iterator it; +
    for (it=myContain.begin(); it!=myContain.end(); +it++) +
    { +
    // do what you have to do to +(*it) +the current item in the container +
    } +

    STL: Algorithms
    Algorithms are functions acting on containers - the most widely used -example of a STL algorithm is the sort -function. -
    Blabla -

    Drawbacks +example of a STL algorithm are the different sorting +algorithms. +

    +STL: Advantages +
    The main and huge advantage 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. +

    STL: Drawbacks
    The main drawback I see in using STL is that it makes it almost impossible to use a debugger normally: whereas access to data is made simple @@ -170,15 +280,14 @@ 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 -v[i] -with gbd, v +v[i] +with gbd, v being an STL vector! -
    But there nonetheless are so many advantages !!!


    Random numbers -
    Evolutionary Algorithms make intensive use of random numbers. Random +

    Evolutionary Algorithms make intensive use of random numbers. Random numbers are simulated in computers by using pseudo-random number generators (RNGs for short), i.e. functions that return series of numbers who look random (w.r.t. some statistical criteria). @@ -211,9 +320,9 @@ related number, e.g. calling time(0), as done for instance in different probability distribution -(e.g. floating point following normal +(e.g. floating point following normal distribution). -

    EO also provides random_generators +

    EO also provides random_generators that can be used in STL call to generate series of random numbers, as in eoPop initializers. @@ -221,29 +330,61 @@ initializers.


    EO conventions and naming style -
    A few naming conventions should help you to navigate more easily through +

    A few naming conventions should help you to navigate more easily through EO:

    • -The name of local variables should start with a lower case letter
      • +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. popSize rather than +pop_size).
    • -The name of the parameters to a function should start with an underscore -(_)
      • +The name of the arguments to a function should start with an underscore, +e.g. -
      The initialization parameters of constructors, for instance,  -should be named from the names of the variables they are used to initialize. +
                void +myfunction(unsigned _popSize){...}
    • -The names of classes should start with eo + an Uppercase letter
      • +The initialization parameters of constructors should be named from the +names of the variables they are used to initialize, e.g. +
        +

        +

      class eoMyClass +
      { +
      public: +
        eoMyClass(unsigned _popSize):popSize(_popSize){...} +
         ... +
      private: +
         unsigned popSize; +
      }; +

    • +The names of classes should start with eo + an Uppercase letter (as eoMyClass +above).
      • + +
    • +The name of the EO template should be EOT. This allows quick understanding +of the inheritance diagrams for functors. and immediate +perception of the arguments and return types of the functors oeprator() +method (as in eoMonOp +or  eoBinOp).
      • + +
       
    • Blabla
    +
    Local: Templates +- +Functors - +STL Library - Random +numbers - EO programming style +
    -
    Tutorial main page - Algorithm-Based -page - Component-Based - Programming -hints - EO +
    General:     Tutorial +main page - Algorithm-Based - Component-Based +- Programming hints - EO documentation