Software framework for metaheuristics

(1)

Software framework for metaheuristics

Parallel Cooperative Optimization Research Group

Laboratoire d’Informatique Fondamentale de Lille

http://paradiseo.gforge.inria.fr

(2)

Outline

• framework.

• ParadisEO-EO (population-based metaheuristics).

• ParadisEO-MO (solution-based metaheuristics).

• EO & MO  hybridized metaheuristics.

• Conclusions and perspectives

(3)

Framework and tutorial application

 Framework dedicated to metaheuristics 

 Tutorial application

 The Traveling Salesman Problem (TSP)

Parallel and Distributed Evolving Objects

(4)

ParadisEO (1/2)

 A templates-based, ANSI-C++ compliant Metaheuristic Computation Framework.

 GForge Project by INRIA Dolphin Team.

 Paradigm Free (genetic algorithms, genetic programming, particle swarm optimization, local searches …).

 Hybrid, distributed and cooperative models.

http://paradiseo.gforge.inria.fr

(5)

 Flexible / a considered problem.

 Generic components (variation operators, selection, replacement, termination, particle behaviors …).

 Many services (visualization, managing

command-line parameters, saving/restarting, …).

ParadisEO (2/2)

http://paradiseo.gforge.inria.fr

(6)

Evolutionary computation, Swarm intelligence : population-

based metaheuristics Tabu Search,

Simulated

Annealing, Hill Climbing:

single solution based

metaheuristics

Multi-objective metaheuristics Parallel and distributed metaheuristics

ParadisEO: Module-based architecture

(7)

Evolutionary computation, Swarm intelligence: population-based metaheuristics Tabu Search,

Simulated

Annealing, Hill Climbing:

single solution based

metaheuristics

Multi-objective metaheuristics Parallel and distributed metaheuristics

ParadisEO: Module-based architecture

(8)

ParadisEO-EO (Evolving Object)

(9)

Available approaches

• Genetic algorithm (GA).

• Genetic programming (GP).

• Evolution strategies (ES).

• Evolutionary algorithm (EA).

• Evolutionary programming (EG).

• Particle Swarm Optimization (PSO).

• Estimation of Distribution Algorithm

(EDA).

(10)

Design concepts

• Each metaheuristic has:

– generic parts  not dedicated to one problem.

– dedicated parts  linked to the problem to

solve.

• The user:

– can directly use the available generic boxes,

– has only to code the information dedicated to his

problem.

(11)

Needed task: designing a representation

 Maybe several ways to do this. The

representation must be relevant regards the tackled problem.

 The user needs to have:

 basic representations available.

 the possibility to use his specific

representation.

(12)

Existent basic representations

(13)

Scheme of one available algorithm:

the evolutionary algorithm

(14)

The Traveling Salesman Problem (TSP)

 “Given a collection of N cities and the distance

between each pair of them, the TSP aims at finding the shortest route visiting all of the cities”.

 Symmetric TSP: candidate solutions.

 Example: ²

)!

1 ( N 

v

₀

v

₄

v

₂

v

₁

8 10

6 9 4

4

6

3

6 Length: 26 v

₃

5

(15)

Representation and evaluation

 We aim at minimizing the total length of the path:

v

₅

v

₃

v

₄

v

₂

v

₁

8 10

6 9 4

4

6

3

6

5

 ₁  i  N dist ( V i , V ₍ i  ₁ ₎ _mod N )

1 2 3 4 5

1 0 6 9 10 8

2 6 0 4 6 4

3 9 4 0 5 6

4 10 6 5 0 3

5 8 4 6 3 0

(16)

Application to the TSP

 Path encoding:

 Every node is assigned a number (e.g. from 0 up to n - 1) and solutions are represented by the ordered

sequence of visited nodes.

(17)

Scheme of one available algorithm:

the evolutionary algorithm

(18)

Scheme of one available algorithm:

the evolutionary algorithm

(19)

Scheme of one available algorithm:

the evolutionary algorithm

(20)

Scheme of one available algorithm:

the evolutionary algorithm

(21)

Scheme of one available algorithm:

the evolutionary algorithm

(22)

Scheme of one available algorithm:

the evolutionary algorithm

(23)

Scheme of one available algorithm:

the evolutionary algorithm

(24)

Scheme of one available algorithm:

the evolutionary algorithm

(25)

Scheme of one available algorithm:

the evolutionary algorithm

(26)

Implementation of an EA (1/9)

RouteInit route_init;

RouteEval full_route_eval;

eoPop <Route> pop (POP_SIZE, route_init);

eoGenContinue <Route> continue (NUM_GEN);

OrderXover crossover;

CitySwap mutation;

eoStochTournamentSelect <Route> select_one;

eoSelectNumber <Route> select (select_one, POP_SIZE);

eoSGATransform <Route> transform (cross, CROSS_RATE, mutation, MUT_RATE);

eoPlusReplacement <Route> replace;

eoEasyEA <Route> ea (continue, full_route_eval, select, transform, replace);

ea (pop);

(27)

Implementation of an EA (2/9)

ea (pop);

(28)

Implementation of an EA (3/9)

ea (pop);

(29)

Implementation of an EA (4/9)

ea (pop);

(30)

Implementation of an EA (5/9)

ea (pop);

(31)

Implementation of an EA (6/9)

ea (pop);

(32)

Implementation of an EA (7/9)

ea (pop);

(33)

Implementation of an EA (8/9)

ea (pop);

(34)

Implementation of an EA (9/9)

ea (pop);

(35)

Other features

• Checkpointing system.

• Configuration file creation and management.

• Visualization tools (link with gnuplot).

• Automatic design tool.

• …

(36)

ParadisEO-MO (Moving Object)

(37)

Design concepts

• Single solution metaheurisitcs

 neighbourhood exploration.

• How can another solution be generated ?

 disturbing the current solution

 make a movement.

• Base of ParadisEO-MO = moMove.

(38)

Available algorithms

Hill Climbing Tabu Search

Simulated Annealing

(39)

Design a move for the TSP

• Reminding the chosen coding.

 Ordered sequence of visited vertices.

2 2 1 5 3 4

3 4 1

1 5 3 4 2 4 3 5 1 2

5 • Some relevant moves:

– Two-opt, City-swap, LK, etc…

(40)

Two-Opt

• Two points within the string are selected and the

segment between them is inverted. This operator put in two new edges in the tour.

2 1 5 3 4

2 5 1 3 4 ₂

3 5

4 1

2 3 5

4 1

Delta = - d(2,1) – d (5,3) + d(2, 5) + d(1, 3)

(41)

Hill Climbing

(42)

How can a Hill Climbing be built ?

• Designing a move operator, its features.

• Designing/implementing the operator to build

the first move (and implicitly the first neighboring candidate).

• Designing/implementing the operator to update a given move to its successor.

• Designing/implementing the incremental evaluation function.

• Choosing the neighbour selection strategy.

• No continuation criterion (stopping as a local

optimum is reached).

(43)

Hill Climbing class

To build the first move

To build the next move

To compute the fitness delta Full evaluation

function

Move selection

strategies

(44)

Two-Opt features (1/2)

• TwoOpt  a two-opt move is a couple of positions in the sequence of visited nodes.

• TwoOptInit  it initializes both

positions to zero !

(45)

Two-Opt features (2/2)

• TwoOptNext  i t increments the second

position if possible. Else, it increments the first position, and reinitializes the second position.

• TwoOptIncrEval  It computes the new length

from the costs of the added/removed edges.

(46)

Neighbour selection strategy

• Deterministic/full: choosing the best neighbor (i.e.

that improves the most the cost function).

• Deterministic/partial: choosing the first processed neighbour that is better than the current solution.

• Stochastic/full: processing the whole

neighborhood and applying a random better one.

(47)

Implementation of a Hill Climbing

**Route route; /* One solution */**

**RouteInit route_init; /* Its builds random routes */**

**route_init (route); /* Building a random starting solution */**

**RouteEval full_route_eval; /* Full route evaluator */**

**TwoOptInit two_opt_init; /* Initializing the first couple of edges to swap */**

**TwoOptNext two_opt_next; /* Updating a movement */**

**TwoOptIncrEval two_opt_incr_eval; /* Efficiently evaluating a given neighbor */**

**moBestImprSelect <TwoOpt> two_opt_move_select; /* Movement selection strategy (elitist) */**

**/* Building the Hill Climbing from those components */**

moHC <TwoOpt> hill_climbing (two_opt_init, two_opt_next, two_opt_incr_eval, two_opt_move_select, full_route_eval);

**/* It applies the HC to the solution */**

hill_climbing (route);

(48)

Simulated Annealing

(49)

How can a Simulated Annealing be built ?

• Designing a move operator, its features.

• Designing/implementing the operator to build a random candidate move.

• Designing/implementing the incremental evaluation function.

• Choosing the cooling schedule strategy.

Independent of the tackled problem

Could be reused from Hill Climbing

(50)

Simulated Annealing class

To compute the fitness delta Cooling schedule

strategy Random

move generator

Full evaluation

function

(51)

The Two-Opt random move generator

• It randomly determines a couple of random positions !

class TwoOptRand : public moMoveRand<TwoOpt> {

public :

void operator () (TwoOpt & move, const Route & route) ; } ;

To be implemented

(52)

Cooling Schedule

• Two (basic) strategies are already implemented: linear and exponential:

– Linear  temp = temp – x.

– Exponential  temp = temp * x.

(53)

**Route route; /* One solution */**

**RouteInit route_init; /* Its builds random routes */**

**route_init (route); /* Building a random starting solution */**

**RouteEval full_route_eval; /* Full route evaluator */**

**TwoOptRand two_opt_rand; /* It builds random candidate movements */**

**TwoOptIncrEval two_opt_incr_eval; /* Efficiently evaluating a given neighbor */**

**moExponentialCoolingSchedule cool_scheme (0.99, 1); /Cooling schedule and associated parameters /**

**/* Building the Simulated Annealing from those components */**

moSA <TwoOpt> simulated_annealing (two_opt_init, two_opt_incr_eval, 100, 100, cool_scheme, full_route_eval);

**/* It applies the SA to the solution */**

simulated_annealing (route);

Implementation of Simulated Annealing

Factor and threshold

Initial temperature and number

of iterations at any step

(54)

Tabu Search

(55)

How can Tabu Search be built ?

• Design a move operator, its features.

• Design/implement the operator to build the first

move (and implicitly the first neighboring candidate).

• Design/implement the operator to update a given move to its successor.

• Design/implement the incremental evaluation function.

• Design/implement the Tabu List.

• Choosing the aspiration criterion.

• Choosing the continuation criterion.

Could be reused from Hill Climbing Independent of the tackled

problem

(56)

Tabu Search class

To build the first

move

To build the next move

To compute the fitness delta Full evaluation

function

Tabu List Aspiration criterion

Continuation criterion

(57)

Tabu List

• Predefined structures:

– List of tabu solutions or tabu moves storing

the tenure (short term memory).

(58)

Choosing an aspiration criterion

• (Basic) implemented strategies:

– No aspiration criterion,

– A tabu move builds a new solution that updates

the best solution found during the search.

(59)

Choosing a stopping criterion

• Use strategies

equivalent to those in ParadisEO-EO EA:

– An optimum is reached, – A given total number of

iterations,

– A given number of gen.

without improvement,

– …

(60)

Implementing a Tabu Search

**Route route; /* One solution */**

**RouteInit route_init; /* Its builds random routes */**

**route_init (route); /* Building a random starting solution */**

**RouteEval full_route_eval; /* Full route evaluator */**

**TwoOptInit two_opt_init; /* Initializing the first couple of edges to swap */**

**TwoOptNext two_opt_next; /* Updating a movement */**

**TwoOptIncrEval two_opt_incr_eval; /* Efficiently evaluating a given neighbor */**

**moNoAspirCrit <TwoOpt> two_opt_aspir_crit; /* Aspiration criterion */**

**moSimpleMoveTabuList <TwoOpt> two_opt_tabu_list; /* Tabu List */**

**moGenContinue <TwoOpt> continue (10000); /* A fixed number of iter. */**

**/* Building the Tabu Search from those components */**

moTS <TwoOpt> tabu_search (two_opt_init, two_opt_next, two_opt_incr_eval, two_opt_aspir_crit, two_opt_tabu_list, continue, full_route_eval);

**/* It applies the TS to the solution */**

tabu_search (route);

(61)

EO & MO  Hybridizing

• Hybridizing allows to combine:

– The exploration power of population-based metaheuristics.

– The intensification power of single solution-

based metaheurisitcs.

(62)

Scheme of an EA in ParadisEO-EO

(63)

ParadisEO-EO/ParadisEO-MO link

(64)

Implementation of an EA

**RouteInit route_init; /* Its builds random routes */**

**RouteEval full_route_eval; /* Full route evaluator */**

**eoPop <Route> pop (POP_SIZE, route_init); /* Population */**

**eoGenContinue <Route> continue (NUM_GEN); /* A fixed number of iterations */**

**OrderXover crossover; /* Recombination */**

**CitySwap mutation; /* Mutation */**

**eoStochTournamentSelect <Route> select_one; /* Stoch. Tournament selection */**

eoSelectNumber <Route> select (select_one, POP_SIZE);

**/* Standard SGA Transformation */**

eoSGATransform <Route> transform (cross, CROSS_RATE, mutation, MUT_RATE);

**eoPlusReplacement <Route> replace; /* replacement */**

eoEasyEA <Route> ea (continue, full_route_eval, select, transform, replace);

**ea (pop); /* Application on the given population */**

(65)

Implementation of an EA hybridized with a hill climbing

**RouteInit route_init; /* Its builds random routes */**

**RouteEval full_route_eval; /* Full route evaluator */**

**eoPop <Route> pop (POP_SIZE, route_init); /* Population */**

**eoGenContinue <Route> continue (NUM_GEN); /* A fixed number of iterations */**

**OrderXover crossover; /* Recombination */**

moHC <TwoOpt> mutation (two_opt_init, two_opt_next, two_opt_incr_eval, two_opt_move_select, full_route_eval);

**eoStochTournamentSelect <Route> select_one; /* Stoch. Tournament selection */**

eoSelectNumber <Route> select (select_one, POP_SIZE);

**/* Standard SGA Transformation */**

eoSGATransform <Route> transform (cross, CROSS_RATE, mutation, MUT_RATE);

**eoPlusReplacement <Route> replace; /* replacement */**

eoEA <Route> ea (continue, full_route_eval, select, transform, replace);

**ea (pop); /* Application on the given population */**

(66)

Software framework for metaheuristics