Del clasificado al webrooming

This section introduces the MSG framework in general terms. Algorithm 3 Master-slave high-level framework

1: P ← buildInitialPopulation(n) {set of n individuals} 2: evaluate(P)

3: while terminating conditions not met do

4: P′ _{← applyGeneticOperators(P) {operators depend on individual repre-}

sentation}

5: evaluate(P′_{) {use slave algorithm}}

6: P ← populationUpdate(n, P, P′₎

7: end while 8: return min(P)

The core idea of our MSG lays in the possibility of splitting the solution construction in two nested phases. In the first phase, the parameters of a solu- tion construction procedure are set by a master solver and in the second phase the solution is actually built by a slave solver. For example, for combinatorial problems there can be constructive procedures based on: the sequence of ob- jects to be included in the solution and/or the decisions to be taken, the set of preassigned variables or the set of hard constraints to be fulfilled.

4.2. MASTER-SLAVE GENETIC FRAMEWORK 43 In a sense, the problem is decomposed into two, interdependent, sub-problems. The solution to the first problem is an input for the second, that actually con- structs a solution. In our TLG framework, the first algorithm is a genetic algorithm, while the second is a problem-specific heuristic. We can say that, in a way, the master explores a search space of “parameters”: the objective value of the points in this space is the value of the solution returned by the slave.

From an implementation point of view two things can be further noted. From an algorithm design perspective, the main advantage of partitioning a problem into master and slave is a clearer separation of concerns, which helps design a more extensible algorithm and allows a simple and neat implementation. In addition to that, an MSG algorithm lends itself to parallel implementations as it is, at its core, a genetic algorithm. The slave algorithm could be executed on different processors, up to one for each offspring to be evaluated. This would save up most of the computing time, because the evaluation of the fitness is the most time consuming task in MSG.

After having fleshed out the its general characteristics, we see that, in order to use the MSG framework, the problem-specific design choices amount to de- ciding a constructive for the slave and the master’s relevant components (genetic operators, update strategy and so on).

Software Frameworks for MSG. From a programmer’s perspective, a MSG algorithm can be easily implemented on top of an existing genetic algorithm framework library in a straightforward way, as was pointed out at the end of the previous section. Every software library that facilitates genetic algorithm development provides, in fact, some way to define a problem-specific fitness function; that hook can be utilised to implement the desired slave procedure.

Though many software frameworks are available1_{, we felt the need to have}

a tool better suited to our needs. As part of the work presented in the fol- lowing sections, we implemented ourselves a C++ software framework, called EasyGenetic[17], to ease the development of MSG algorithms. The main dif- ference between EasyGenetic and other popular evolutionary algorithm frame- works, such as ParadisEO [41], galib [231] or ECJ [68], is that it is heavily based on template metaprogramming techniques 2 _{to eliminate runtime abstraction}

penalties and to allow more flexibility in design.

Many GA frameworks provide typical chromosome representations, typi- cally one- or two-dimensional numeric arrays; other frameworks also include tree-based chromosomes for genetic programming. In EasyGenetic we take a different standpoint. Inspired by another software framework, spGAL [215], EasyGeneticis designed to encourage the programmer to write reusable generic code. “Generic” in this context means that every component abstracts away from the actual implementation of the chromosome. Chromosomes can thus be as simple as bitstrings or as complex as trees, graphs or totally different objects altogether. The only constraints between algorithm components (recombina- tion operators, selection strategy and so on) and chromosomes is represented by concepts. Concepts are specifications of structural interfaces, as opposed to the usual definition of interface found in mainstream OOP languages, such

1_{At the time of the writing, there are 284 projects on SourceForge [214] categorised under}

“Genetic Algorithm”, 88 of which are written in C++, our language of choice.

2_{ParadisEO makes use of design patterns based on template instantiation, but it does not}

as Java, and are of fundamental importance in writing generic functions [98]. Concepts are a way to specify structural subtyping, that is, a form of subtyp- ing that is roughly based on which operations a type provides. As opposed to nominal subtyping, where the programmer must explicitly state the subtype relation, concepts allow for a more “open” form of subtyping: every type that meet a concept’s requirements can be automatically used, without programmer intervention, wherever an object of that particular concept is required. For in- stance, a sorting function might require that the objects it sorts all implement a comparison operator. A similar form of subtyping, popular among dynami- cal languages, is called Duck typing [67], with the main difference that struc- tural subtyping with concepts is enforced at compile-time, while Duck typing is checked at run-time. With concepts and metaprogramming, we are able to have a great deal of expressiveness without sacrificing compile-time checks and runtime efficiency. For example, EasyGenetic can support crossover operators that take an arbitrary number of parent chromosomes, say n, and, contemporar- ily, are naturally implemented by a simple functions with n arguments. Other frameworks, instead, allow only a fixed number of recombinants, typically one (asexual crossover) or two (sexual crossover) [231].

Further information on EasyGenetic is available in [21, 22].