The term evolution engine denotes the different parts that simulate
-the Darwinism in Evolutionary Algorithms.
+
Introduction
+
The term evolution engine denotes the different parts that simulate
+the Darwinism in Evolutionary Algorithms.
The fittest individuals are more likely to
+ The fittest individuals are more likely to
reproduce and survive.
Darwinism takes place in two different phases of an EA, though in many -popular variants, only one phase is activated. +popular +variants, only one phase is activated.
Selection is the Darwinistic choice of parents
-that will be allowed to reproduce.
+that will be allowed to reproduce.
Replacement takes place after reproduction,
-and is the Darwinistic choice of those individuals that will survive,
+and is the Darwinistic choice of those individuals that will survive,
i.e. become the parents of the next generation.
Replacement
+
The replacement phase takes place after the birth
+of all offspring through variation operators. The idea is to close
+the generation loop, i.e. to end up with a population of individuals that
+will be the initial population of next generation. That population will
+be built upon the old parents and the new-born offspring.
+In all algorithms that come up with EO, the population
+size is supposed to be constant from
+one generation to the next one - though nothing stops you from writing
+an algorithm with varying population size.
+
Replacement: The
+interface
+
The abstract class for replacement procedures is the functor class
+eoReplacement,
+and the interface for its operator()
+is
+
void operator()(const eoPop<EOT>& +_parents, eoPop<EOT>& _offspring)
which you could have guessed from the inheritance tree for class eoReplacement.,
+as you see there that eoReplacement derives
+from class eoBF<const eoPop<EOT>&,
+eoPop<EOT>&, void>.
+
This means that it takes 2 populations
+(called, for obvious anthropomorphic reasons, _parents and _offspring :-)
+and puts the result into population offspring (as _parents is passed as
+constant
+population).
+
Note: After the replacement step, +all algorithms swap the parents and offspring populations - this is why +the result of the replacement is put into the _offspring population -- +the _parents being there untouched until the very last moment. +
Replacement: Instances +
+
Available instances of eoMerge objects
+are eoPlus, that simply adds
+the parents to the offspring, or eoElitism,
+that adds only some of the (best) parents to the offspring. A special case
+of eoElistism is eoNoElitism,
+an eoMerge that does nothing.
+
+
Available instances of eoReduce are eoTruncate, +that deterministically keeps only the required number of individuals, taking +the best ones, and eoEPReduce +that usees the EP stocahstic tournamenent to reduce the population. +
Available instances of eoMergeReduce replacement +procedures are built on the above, and include +
Replacement: Adding
+(weak) elitism
+
You can add what is called weak elitism
+to any replacement by encapsulating it into an eoWeakElitismReplacement
+object. Weak elitism ensures that the overall best
+fitness in the population will never decrease:
+if the best fitness in the new population is less than the best fitness
+of the parent population, then the best parent is added back to the new
+population, replacing the worse.
+
Within EO, this is very easy to add: +
First, declare your replacement functor (here, generational, but it
+can be any replacement object):
+
eoNoReplacement<Indi> genReplace;
+
Then wrap the weak elitism around it:
+
eoWeakElitismReplacement<Indi> replace(genReplace);
+
and use now replace as your replacement procedure within your algorithm.
+
Note: of course, adding weak elitism to +an elitist replacement makes no sense - but will not harm either :-)
Popular
evolution engines
-
-
-
+
The most popular evolution engines are listed below, together with
+the way to use them in EO. If you don't find your particuler algorithm,
+please send it to us, and we might include it here!
+
+
+ Note: In the
+previous files (Bit - Real)
, the last 2 types were deduced from the first (2nd argument = fitness
type of EO object, third = first).
Note: In
-the previous files (Bit - Real)
+
+
@@ -113,24 +115,28 @@ the eoPop has no idea of the eval function, so it has to be done from outside!!!
You can now use
different
crossover
-and mutation
-operatorsin
-the same algorithm, choosing among them according to
+and
+mutation
+operatorsin the same algorithm,
+choosing among them according to
relative
rates. The
class eoPropCombinedxxxOp,
where
-xxx is either Mon (for mutations, of class eoMonOp)
-or Quad (for crossovers, of class eoQuadOp),
+xxx is either Mon (for mutations, of class eoMonOp)
+or Quad (for crossovers, of class eoQuadOp),
is derived from the corresponding eoxxxOp class. When applying the eoPropCombinedxxxOp,
one of the eoxxxOp it contains is chosen by a roulette
-wheel, according to their respective rates, and is applied to the arguments.
+wheel, according to their respective rates, and is applied to the arguments.
+For more details on these classes, go to the top-down
+corresponding pages, or to their respective documentation pages.
Note: The operators have to be encapsulated -into an eoTransform object -(Bit - Real) +
Note: The +operators have to be encapsulated into an eoTransform +object (Bit - Real) to be passed to the eoEasyEA algorithm. The eoSGATransform is a simple eoTransform diff --git a/eo/tutorial/html/eoOperators.html b/eo/tutorial/html/eoOperators.html index 5803ae13..5ec0e8ef 100644 --- a/eo/tutorial/html/eoOperators.html +++ b/eo/tutorial/html/eoOperators.html @@ -2,55 +2,326 @@
- +Variation operators involving two individuals are called
-crossover operators.
-They can either modify one of the parents according
-to the material of the other parent, or modify both parents. In EO, the
-former are called Binary operators and the latter Quadratic operators.
-
-
Variation operators involving one single individual are called mutation -operators. -
Note that in EO you can define and use variatio operators that generate -any number of offspring fromany number of parents. These are called general -operators, and require advanced knowledge of EO. -
Crossover
-
Crossover operators involve two parents, and can modify one of them,
-or both of them.
-
Using crossover operators -
Mutation
-
Mutation operators modify one single individual. The corresponding
-EO class is called eoMonOp.
-
-
Variation
+Operators
+
Variation operators modify individuals, or, equivalently, move them
+in the search space. They are almost always stochastic,
+i.e. they are based on random numbers, or equivalently, perform random
+modifications of their arguments. Variation operators are classified depending
+on the number of arguments they use and/or modify.
+
Variation operators involving two individuals are called crossover
+operators. They can either modify one of the parents according to the
+material of the other parent, or modify both parents. In EO, the former
+are called Binary operators and the latter Quadratic operators.
+
Variation operators involving one single individual are called mutation
+operators.
+
In EO you can also define and use variation operators that generate
+any number of offspring from any number of parents (sometimes termed orgy
+operators). They are called general operators.
+
Though most the historical evolutionary algorithms used at most one +crossover and one mutation (see e.g. the Simple Genetic Algorithm in lesson1), +the trend now in evolutionary computation is to combine operators, choosing +at run-time and for each individual which operator to apply. This can be +done in the framework of simple operators, combining for instance several +mutations into a variation operator that chooses one of them according +to user-defined preferences: such combinations are called in EO proportional +combination of simple operators (see e.g. how to define and use such +combined operators in the SGA of lesson2). +
Finally, there are many other ways to combine different variation operators +of different kind. Within EO, you can choose to apply many different types +of operator to the population, either in turn (this is called sequential +combination) or by randomly choosing among a set of operators at a given +time (this is proportional combination, generalizing the one defined for +simple operators). You can of course mix and interleave both approaches +at will, and this is described as general +combination of general operators. +
EO implementation: all variation
+operators in EO derive from the base (abstract) class eoOp
+(as usual, click to see the inheritance diagram). blabla
+
+
The characteristic of crossover operators is that they involve two parents. +However, there are crossover operators that generate two parents, and some +that generate one parent only, and both types are available in EO. The +former type (2 --> 2) is termed quadratic crossover operator, and is implemanted +in the eoQuadOp class; the latter type +(2 --> 1) is termed binary operator and is implemanted in class eoBinOp. +Both classes are, as usual, templatized by the type of individual they +can handle (see documentation for eoBinOp +and eoQuadOp). +
Note: Whereas it is straightforward +to create a binary crossover operator from a quadratic one (by discarding +the changes on the second parent), the reverse might prove impossible (imagine +a binary crossover that simply merges the parents material: there is no +way to generate two new parents from that!). +
Interfaces:
+
The general approach in EO about simple variation operators is to perform
+in-place
+modifications, i.e. modifying the arguments rather than generating
+new (modified) individuals. This results in the following interfaces for
+the functor objects eoBinOp and eoQuadOp:
+
void operator()(EOT & , const EOT &)
+for eoBinOp (note the const)
+
void operator()(EOT & , EOT &
+)
+for eoQuadOp
+
which you could have guessed from the inheritance diagrams up to the +eoBF abstract class. You can also guess that only the first argument will +be modified by an oeBin object, while both arguments will be modified by +an eoQuad object. +
Using crossover operators:
+
Directly applying crossover operators is straightforward from the interface
+above:
+
eoBinOpDerivedClass<Indi> myBinOp(parameters);
+// use constructor to pass
+
eoQuadOpDerivedClass<Indi> myQuadOp(parameters);
+// any useful argument
+
Indi eo1= ..., eo2= ...; //
+the candidates to crossover
+
myBinOp(eo1, eo2);
+// will modify eo1 only
+
myQuadOp(eo1, eo2);
+// will modify eo1 and eo2
+
However, you will hardly have to do so, as operators are used within
+other classes, and are applied systematically to whole sets of individuals
+(e.g. that have already been selected, in standard generational evolutionary
+algorithms).
+
Hence the way to use such operators will more likely ressemble, if
+you are using for instance an SGA, this (definition,
+usage).
+See also the different ways that are described below, encapsulating the
+operators into combined operators objects.
+
+
Writing a crossover
+operator:
+
There are only two things to modify in the template
+class definitions provided (apart from the name of the class you are
+creating!)
+
+
Interfaces:
+
The general approach in EO about simple variation operators is to perform
+in-place
+modifications, i.e. modifying the arguments rather than generating
+new (modified) individuals. This results in the following interface for
+the functor objects eoMonOp:
+
void operator()(EOT & ) +
which you could have guessed from the inheritance diagrams up to the +eoUF abstract class. +
Using mutation operators:
+
Directly applying mutation operators is straightforward from the interface
+above:
+
eoMonOpDerivedClass<Indi> myMutation(parameters);
+//pass parameters in constructor
+
Indi eo1 = ...;
+// eo1 is candidate to mutation
+
myMutation(eo1);
+// will modify eo1
+
However, you will hardly have to do so, as operators are used within
+other classes, and are applied systematically to whole sets of individuals
+(e.g. that have already been selected, in standard generational evolutionary
+algorithms).
+
Hence the way to use such operators will more likely ressemble, if
+you are using for instance an SGA, this (definition,
+usage).
+See also the different ways that are described below, encapsulating the
+operators into combined operators objects.
+
Writing a mutation
+operator:
+
There are only two things to modify in the template
+class definitions provided (apart from the name of the class you are
+creating!)
+
The best thing to do is to go to the Lesson2 +of the tutorial, where everything is explained. +
+
+
There are two main ways to use and combine general operators in EO: +the proportional combination, similar to what has been described for simple +operators above, and the sequential combination, which amounts to apply +all operators in turn to a bunch of individuals, each operator being applied +with a specific probability. +
Proportional combinations behave +like a unique operator: when it is called upon a population of candidates, +an eoProportionalOpContainer enters +the following loop: +
while there are individuals left in the candidate population +
for all operators it contains, apply the operator to the candidate population, +that is +
Remark: there is actually a single list
+of individuals that is maintained through a clever mecahnism of mark, rewind
+and unmark, but that's a purely technical matter. If you are interested,
+go and check the eoOpContainer and the eoSequentialOpContainer code.
+
+
Adding operators to a container:
+
The basic function to add an operator to an eoOpContainer is the method
+add
+from class eoOpContainer.
+
It is similar to all other add
+methods in other Combined things in eo (as the simple eoProportionalCombinedXXXop
+described above, but also the eoCombinedContinue class or the eoCheckPoint
+class).
+
The syntax is straightforward, and it works with any of the operator
+classes defined above:
+
someOperatorType<Indi> myOperator;
+
eoXXXOpContainer<Indi> myOpContainer;
+
myOpContainer.add(myOperator, rate); //
+rate: double whose meaning depends on XXX
+
where XXX can be one of Proportional and Sequential.
+
However, the way rate
+will be used is highly dependent on the type of OpContainer your are creating
+there:
+
+