Lesson 2 - Lesson 4 - Main page - Algorithm-Based - Component-Based - Hints - EO documentation

Tutorial Lesson 3: input/output

In this lesson, you will still use the same Evolutionary Algorithm, BUT in a much more user-friendly way. You will discover how to First, but you should now have done it without being told, go into the Lesson3 sub-dir of the tutorial dir and type make. This will compile the SecondBitEA and SecondRealEA programs.

You can then either

As already said, the behavior of the algorithm will be exactly the same as the previous one as far as optimization is concerned. Only the input (of algorithm parameters) and output (of program results) will be very different.
Hence, the sections corresponding to the fitness function, the initialization, the variation operators, the evolution engine and the algorithm itself are almost identical (apart from variable name changes).
eoParser: parameter input
The first two examples of Lessons 1 and 2 had a very crude way to set parameter values: they were hard-coded, and you had to recompile the whole program to change a single value. We shall now see now to set parameter values in a flexible way (though we're still looking for volunteers to create a Graphical User Interface :-)
Two base classes are used for that purpose:
eoParser: Modifying parameter values at run-time:
Using an eoParser object, the parameter values are read, by order of priority
  1. from the command-line
  2. from a text file
  3. from the environment (forthcoming, if somebody insists)
  4. from default values
The syntax of parameter reading is a keyword-based syntax, now traditional in the Unix world:
eoParser: Programming parameter input:
The code of SeconBitEA provides examples of parameters reading. Lets take the example of the random number generator seed.  Of course, you first need to declare an eoParser object (it needs the standard argc and argv in its constructor). There is however another way to achieve the same result in less lines of code - with a different memory management. This is what is done in the code for eoRealEA. The same parameter for the random number generator seed is read, but in one single line of code.  The only difference is that now you cannot access the eoValueParam object itself - but this is not often necessary.
Be careful to ensure that the type of the default value in the call to eoParameterLoader::createParam method as this is the only way the compiler can desambiguate the template (remember that eoParameterLoader is a base class for eoParser.

eoState: saving and loadingYou might have noticed in the  read_param described above a new parameter named load_name. Now if you go to the init section of the code, you will see an alternative way of initializing the population: if load_name is an empty string, then we do as in the preceding example and use an eoInitFixedLength object. However, if a load_name name was entered, the population is read through the inState.load(load_name) instruction. Moreover, the comment says "Loading pop and rng".

This is made possible using the eoState class. eoState objects maintain references to eoObjects that have both an input method (readFrom) and an output method (printOn), i.e. that derive from the base class eoPersistent. You must first register object into a state, and can then save them to a (text) file, and later read them from that file using the load method, as done here.
Of course, you can call the save 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 construct to perform some systematic actions every generation - like saving things (using eoState objects described above), computing statistics on the population, updating dynamical parameters or displaying information.

eoCheckpoint objects are eoContinue objects that contain pointers to different types of objects. When their operator() method is called (i.e. every generation in the examples up to now), they first call the operator() methods of all object they contain, and then return their result as an eoContinue object (i.e. should we continue or stop).
Programming: To do something every generation, you simply need to add an object whose operator() does what you want to the eoState that you will use as continuator in the algorithm.

eoCheckpoint: Stopping
The eoContinue part of an eoCheckpoint is a single object, passed to the constructor. If you want more that one stopping criterion, use an eoCombinedContinue object as described in Lesson2.

eoCheckpoint: Computing statistics
Statistics are computed using eoStat objects, i.e. functor objects whose operator() receives as argument a reference to a population as argument, and can hence compute whatever is needed over that population. eoStat objects are templatized over the type of what they compute (e.g. double, or pair<double>, or ...). But looking at the inheritance diagram of the eoStat class, you find that eoStat objects are also eoValueParam objects. And this allows eoStat to be used within eoMonitor object, and hence displayed to the user!

Statistics: Available instances
Some widely used statistics are already available (and of course you can build you own!).

Statistics: Adding to the checkpoint
To compute more statistics when your algorithm is running, simply declare the corresponding eoStat objects, and add them to the eoCheckpoint you use in the algorithm. But it hardly makes any sense if you don't monitor those statistics (i.e. either displaying them on the screen, or storing them into a file): see next section!

Note: actually, there are 2 distinct classes that compute and give access to statistics: eoStatand eoSortedStat. As its name indicate, the latter is used whenever computing the statistics require a sorted population: not only this avoids to sort the population many times, but also it avoids changing the order of the population at all as eoSortedStat objects work on a temporary vector of fitnesses . But as far as their usage is concerned, its makes no difference.

eoCheckpoint: Monitoring eoParameters
The eoMonitor objects are used to display or store to a file a set of eoValueParam objects.

Monitors: Available instances
A few monitors are available in the EO distribution:

Monitors: Adding to the checkpoint
To display something while the algorithm is running, you need to declare an eoMonitor object, add some objects (that must be eoValueParam objects) to that monitor, and of course add the monitor to the eoCheckpoint you use in the algorithm.

eoCheckpoint: Updating things
The last type of objects that  eoCheckpoint can handle are eoUpdater objects. You should simply encapsulate in an eoUpdater anything you wish to do which does not fit into one of the above category. Note that their operator() method does not receive any argument.

Updater: Available instances: A few updaters are available in the EO distribution:

Updater: Adding to the checkpoint
A very simple example of using an eoUpdater is given in the code for SecondBitEA: First declare an eoValueParam object, then use it to construct an eoIncrementor that you must add to the eoCheckpoint in order to activate its update. You can then use the parameter for your purpose, for instance as a first coordinate for a monitor.
Note also how to use the statesavers: first declare a state, then register whatever you think necessary to that state, then pass the state to some state-saver - and don't forget to add the statesavers to the current eoCheckpoint.

Exercise 1:
Exercise 2:
Write the eoDiversityStat stat computation and test it. Thanks to send us the code!

Exercise 3:
Write the code for an eoGnuplotSecondStatMonitor that would display the eoSecondMomentStat (i.e. take into account the standard deviations and display them as error-bars.
Again, send us the code afterwards, thanks :-)

Lessons learned: In next lesson you will find out that many adaptive techniques (the state-of-the-art in Evolutionary Computation) can easily be programmed through the eoUpdater construct.

Lesson 2 - Lesson 4 - Main page - Algorithm-Based - Component-Based - Hints - EO documentation

Marc Schoenauer

Last modified: None of your business!