Add tutorial READMEs and fix tutorial return codes
Add README.md files for moeo/tutorial/Lesson{1-4}, smp/tutorial/Lesson{1-4},
and mo/tutorial/Lesson9 — these tutorials had no documentation.
Fix return 1 → return 0 in 28 tutorial main() functions across mo/ and
smp/ that unconditionally returned failure status.
This commit is contained in:
parent
54a44a177f
commit
c1a44fd2a6
37 changed files with 371 additions and 30 deletions
23
smp/tutorial/Lesson1/README.md
Normal file
23
smp/tutorial/Lesson1/README.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# Master/Workers wrapping with eoEasyEA
|
||||
|
||||
Wraps a standard eoEasyEA with the ParadisEO-SMP parallel evaluation model,
|
||||
applied to the Quadratic Assignment Problem (QAP).
|
||||
|
||||
The QAP assigns facilities to locations to minimize cost (flow x distance).
|
||||
The representation is a permutation.
|
||||
|
||||
## Running
|
||||
|
||||
From the `build/smp/tutorial/Lesson1` directory:
|
||||
|
||||
```shell
|
||||
./lesson1_eoEasyEA lesson1_eoEasyEA.param
|
||||
```
|
||||
|
||||
## How it works
|
||||
|
||||
The key idea: ParadisEO-SMP parallelizes evaluation by wrapping an existing
|
||||
sequential algorithm. The algorithm code itself stays the same. `QAP.h`
|
||||
defines the problem representation and evaluation, `QAPGA.h` defines the GA
|
||||
operators, and `parserStruct.h` + `utils.h` handle parameter parsing and
|
||||
instance loading. See also `lesson1_data.dat` for the problem instance.
|
||||
|
|
@ -23,8 +23,8 @@ same conditions as regards security.
|
|||
The fact that you are presently reading this means that you have had
|
||||
knowledge of the CeCILL license and that you accept its terms.
|
||||
|
||||
ParadisEO WebSite : http://paradiseo.gforge.inria.fr
|
||||
Contact: paradiseo-help@lists.gforge.inria.fr
|
||||
ParadisEO WebSite : https://nojhan.github.io/paradiseo/
|
||||
Contact: https://github.com/nojhan/paradiseo/issues
|
||||
*/
|
||||
|
||||
/**
|
||||
|
|
@ -125,5 +125,5 @@ int main(int argc, char **argv)
|
|||
delete[] b;
|
||||
|
||||
|
||||
return 1;
|
||||
return 0;
|
||||
}
|
||||
|
|
|
|||
30
smp/tutorial/Lesson2/README.md
Normal file
30
smp/tutorial/Lesson2/README.md
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
# Homogeneous island model
|
||||
|
||||
Three islands running the same algorithm (`eoEasyEA`) with a complete
|
||||
topology — all islands exchange individuals with all others.
|
||||
|
||||
Same QAP problem as Lesson 1.
|
||||
|
||||
## Running
|
||||
|
||||
From the `build/smp/tutorial/Lesson2` directory:
|
||||
|
||||
```shell
|
||||
./lesson2_homogeneous
|
||||
```
|
||||
|
||||
The problem instance is loaded from `../lessonData.dat`.
|
||||
|
||||
## How it works
|
||||
|
||||
All islands share the same operators (evaluation, selection, crossover,
|
||||
mutation, replacement) but can have different parameters. The topology
|
||||
and island model are set up with:
|
||||
|
||||
```c++
|
||||
Topology<Complete> topo;
|
||||
IslandModel<Indi> model(topo);
|
||||
```
|
||||
|
||||
Each island gets its own population and generation limit, then the model
|
||||
runs them in parallel and handles migration.
|
||||
27
smp/tutorial/Lesson3/README.md
Normal file
27
smp/tutorial/Lesson3/README.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# Heterogeneous island model
|
||||
|
||||
Two islands running different algorithms: an `eoEasyEA` on the QAP problem
|
||||
and a PSO on a bitstring problem, connected via conversion functions.
|
||||
|
||||
## Running
|
||||
|
||||
From the `build/smp/tutorial/Lesson3` directory:
|
||||
|
||||
```shell
|
||||
./lesson3_heterogeneous
|
||||
```
|
||||
|
||||
## How it works
|
||||
|
||||
When islands use different representations, you need conversion functions
|
||||
to translate individuals during migration. In this example, `fromBase()`
|
||||
and `toBase()` convert between the QAP permutation and the PSO bitstring:
|
||||
|
||||
```c++
|
||||
Indi2 fromBase(Indi& i, unsigned size) { ... }
|
||||
Indi toBase(Indi2& i) { ... }
|
||||
```
|
||||
|
||||
The conversions here are dummy placeholders (they just create random
|
||||
individuals), but in a real application you would implement meaningful
|
||||
mappings between representations.
|
||||
31
smp/tutorial/Lesson4/README.md
Normal file
31
smp/tutorial/Lesson4/README.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# Dynamic island topology
|
||||
|
||||
Three islands start with a ring topology and switch to a complete topology
|
||||
after 10 seconds of computation.
|
||||
|
||||
Same QAP problem as Lessons 1-2.
|
||||
|
||||
## Running
|
||||
|
||||
From the `build/smp/tutorial/Lesson4` directory:
|
||||
|
||||
```shell
|
||||
./lesson4_topology
|
||||
```
|
||||
|
||||
## How it works
|
||||
|
||||
A callback function registered with the islands triggers the topology
|
||||
change:
|
||||
|
||||
```c++
|
||||
void changeTopo(IslandModel<Indi>* _model, AbstractTopology& _topo)
|
||||
{
|
||||
// ... after 10 seconds:
|
||||
_model->setTopology(_topo);
|
||||
}
|
||||
```
|
||||
|
||||
The topology can be changed at runtime via `model.setTopology()`, so you
|
||||
can implement adaptive communication patterns based on time, convergence,
|
||||
or any other criterion.
|
||||
Loading…
Add table
Add a link
Reference in a new issue