diff --git a/eo/tutorial/html/eoLesson3.html b/eo/tutorial/html/eoLesson3.html index 5213ec9ae..80726afe8 100644 --- a/eo/tutorial/html/eoLesson3.html +++ b/eo/tutorial/html/eoLesson3.html @@ -2,7 +2,7 @@ - + Tutorial: Lesson 3 @@ -142,7 +142,7 @@ See the parameter section of the Component-Based tutorial, or wait until class, whose only purpose is the input of parameters. -
eoParser: +
eoParser: Modifying parameter values at run-time:
Using an eoParser object, the parameter values are read, by order of priority @@ -172,10 +172,10 @@ the general syntax to modify parameter value at run-time is (either from the command-line or in a text file)
               - --longKeyword=value     or     -cvalue    -if 'c' is the short keyword (though -c=value also works) +if 'c' is the short keyword (though -c=value +also works)
 
  • so, after compiling the executable for Lesson 3 (make @@ -183,12 +183,10 @@ lesson3 at system prompt in Unix), you can try to type in

    •                 - SecondBitEA
    and see the algorithm run as before (OneMax optimized on 8-bits bitstrings). But you can now type in
                    - SecondBitEA --vecSize=100
    and see the output of the optimization of OneMax on 100-bit bitstrings.
      @@ -196,7 +194,6 @@ But you can now type in Take a look at all available parameters by typing in
                    - SecondBitEA --help
    or by going into the code: all parameter inputs have been grouped in the @@ -208,7 +205,8 @@ it contains the list of all actual parameters used, and can directly be used as parameter input file: change the file name (e.g. to SecondBitEA.param), edit it, change whichever parameter you want, and type in -
                      +
                     + SecondBitEA @SecondBitEA.param
    and you will see all values that you defined into the file taken into account. @@ -247,7 +245,9 @@ of eoParam returns a reference, so you can eventually modify its value somewhere else later (though of course this is not any useful for variable seed!). - +There is however another way to achieve the same result in less lines of +code - with a different memory management (see Lesson4). +

    eoState: saving and loadingYou might have @@ -276,7 +276,11 @@ method, as done here. method for an     eoState object anywhere in the code. But the checkpointing mechanism offers you better ways to do that - and it's so easy .... -

    +

    Note that an eoState alos has another use in EO whan it comes to memory +management: it can be a repository of pointers that are not allocated within +obects - allowing to delete them by simply deleting the eoState (see Lesson +4). +

    eoCheckpoint: every generation I'd like to ...
    The checkpointing mechanism is a very powerful @@ -544,4 +548,4 @@ documentation
    Last modified: None of your business! - + diff --git a/eo/tutorial/html/eoLesson4.html b/eo/tutorial/html/eoLesson4.html index e8b518ab7..087bf4960 100644 --- a/eo/tutorial/html/eoLesson4.html +++ b/eo/tutorial/html/eoLesson4.html @@ -2,12 +2,12 @@ - + Tutorial: Lesson 4 -Lesson 3 - -Lesson +Lesson 3 - +Lesson 5 - Main page - Algorithm-Based @@ -485,8 +485,8 @@ Bounds for uniform initialization of the real variables. The syntax for this parameter given in the objectBounds parameter description below. This argument is mandatory, furthermore the given bounds must be bounded. -The default is [-1,1] -for all variables. +The +default is [-1,1] for all variables.
    Note that this parameter is independent of the objectBounds parameter below.

    # --sigmaInit=0.3 # -s : @@ -726,10 +726,88 @@ correlated mutation. Default is 0.0873


    Programmer's -guide -
    Lesson +guide     +

    At the moment, you will have to browse in the source (colored!) code +(Bit - Real) almost by yourself, sorry. +

    Note that the main file is now very slim, as it only contains calls +to some make_xxx +functions - these functions contain the actual code, very similar to the +code of Lesson3, except for the memory management, performed through an +eoState +object (notice that all make_xxx +calls have an eoState as second parameter). +

    Programmer's guide: The +make_xxx files +

    Interface: all make_xxx +files have as first two parameters an eoParser +and an eoState. +The eoParser +is be used within all functions to parse the command-line and/or a parameter +file in order to read any relevant user-parameter, while the eoState +is used here to store all pointers to be allocated inside the function +(see Programming hints for more +detailed explanations). +

    There are 2 types of make_xxx +files: the ones that do depend on representation, defining the genotype +and +initialization (make_genotype_xxx, +with xxx being the type of genotype) and variation operators (make_op_xxx), +and the one that are truly representation-independent (make_pop, +make_continue, make _checkpoint, make_algo and +make_run). +
    The former are located in the directory corresponding to the actual +genotype (src/ga +for eoBit, src/es +for eoReal and all eoESxxx genotypes). The latter are in the directory +src/do. +

    If you take a close look at the code of make_continue +for instance, you will first notice that ... the function declared there +is called do_make_continue +and is not the one you are calling in +the main file, though it has the same parameters as arguments. +
    The explanation lies within the file make_continue_xxx.cpp +(with xxx = ga or real/es)which, as its color (and name)  should have +told you about, are representation-dependent: in fact the make_continue_xxx.cpp +files only instanciates the general <EOT> template into one of the possible +template for eoBit or eoReal/eoES - and this trick allows to compile +them separately! +

    The other thing that you should notice is that the code there is very +similar to the code that was in Lesson 3,  regarding parameter reading +and type of object that are allocated - except for memory management. This +goes for all make_xxx +files - so the only thing you need to understand how it goes is to look +at the memory management section. +

    Pros: you don't have to handle a +huge main function - and many of the make_xxx files can be directly used +in different applications (this is called modularity +:-))) +
    More interesting, you can even compile +the make_xxx +files separately for a given target +template, and link them e.g. with your fitness function when it is ready +(remember that up to now you needed to compile everything altogether by +including the code into your mail fine). Indeed, if you do a global make, +you will notice that there are additional libraries compiled in src/ga +and src/es +... +

    Cons: It makes the code a little +more complex to understand, first because of the indirection needed for +pre-compilation with a given template, and second because of the memory +management that this imposes. +

    Programmer's +guide: Memory management +
    As already said, all functions have an eoState +as second argument - and that object is used to store the functor objects +that were simply declared as variables of the main function up to now : +see Programming hints for more +detailed explanations and take a look at the code of make_continue +for instance, you will see the implementation of the memory management +in action. +
      +

    +

    Lesson 3 - -Lesson 5 - +Lesson 5 - Main page - Algorithm-Based - Component-Based diff --git a/eo/tutorial/html/eoOperators.html b/eo/tutorial/html/eoOperators.html index 8884adaae..87ff6491e 100644 --- a/eo/tutorial/html/eoOperators.html +++ b/eo/tutorial/html/eoOperators.html @@ -2,7 +2,7 @@ - + Variation Operators @@ -148,27 +148,27 @@ an eoQuad object.
    Directly applying crossover operators is straightforward from the interface above:
    eoBinOpDerivedClass<Indi> myBinOp(parameters); - -//  use constructor to pass +//  +use constructor to pass
    eoQuadOpDerivedClass<Indi> myQuadOp(parameters); //  any useful argument
    Indi eo1= ..., eo2= ...;   // the candidates to crossover
    if (myBinOp(eo1, eo2)) -
       { ...                  +
       { ...               // eo1 has been modified, not eo2
       } -
    else ...                  +
    else ...               // none has been modified
    if (myQuadOp(eo1, eo2)) -
       { ...                  +
       { ...               // both eo1 and eo2 have been modified
       } -
    else ...                  +
    else ...               // none has been modified

    However, you will hardly have to actually apply operators to individuals, @@ -225,13 +225,12 @@ above:
    Indi eo = ...;           // eo is candidate to mutation
    if (myMutation(eo)) -
       { ...     - -// eo has been modified +
       { ...    // +eo has been modified
       } -
    else         - -// eo has not been modified +
    else      +// +eo has not been modified

    However, you will hardly have to actually apply operators to individuals, as operators are used within other classes, and are applied systematically to whole sets of individuals (e.g. that have already been selected, in @@ -303,29 +302,47 @@ but rather through objects of type eoOpContainer<

    This results in the following general interface for an eoGenOp: It receives as argument an eoPopulator, gets the individuals it needs using the operator*, -and must handle the positinning of the  using the operator++ -method. +and must handle the positinning of the  using the ++operator +method (Warning: the operator++ +method is not defined, as recommended by many good-programming-style books).

    bool apply()(eoPopulator& _pop)
    {
       EOT& parent1 = *_pop; // select the first parent -
       ++_plop;      - -// advance once for each selected parents +
       ++_plop;   +// +advance once for each selected parents
       ...
       EOT& parentN = *_pop; // select the last parent -
            - -// don't advance after the last one: _plop always +
           // +don't advance after the last one: _plop always
                // points to the last that has already been treated

    // do whatever the operator is supposed to do
    } +

    Warning: as said above, an eoPopulator +should always point to the last individual that has already been treated. +This is because it is intended to be used within a loop that looks like +(see e.g. eoBreeder +class): +

          eoSelectivePopulator<EOT> +popit(_parents, _offspring, select);    // eoSelect +is an eoSelectOne +
          while (_offspring.size() +< target) +
              +{ +
                   +op(popit); +
                  +++it; +
              +}

    What happens next? Well, it all depends on how many parents and how many offspring your general op needs: