\g System's Manual

GUIDE System's Manual

Luis Da Costa and Marc Schoenauer

This document constitues is the System's Manual for GUIDE. An updated copy is kept on GUIDE's forge website, http://gforge.inria.fr/projects/guide/, under the Documents tab.
GUIDE is a software layer providing a common interface to different evolutionary libraries. The whole product comes accompanied with a Graphic User Interface (GUI) that extends the library's facilities to a wide range of users, expert practitioners of Evolutionary Computation (EC) or not. We think this is a very important point that deserves to be discussed and pinpointed, as we did in our latest communication1 [1]. The center of our argument is presented in the following paragraphs.
One of the important research motivations in our research group (TAO, tao.lri.fr) is based on the idea of bringing the methods of our domain, Evolutionary Computation (EC), closer to general, non-expert, users. Indeed, despite impressive accomplishments, Evolutionary Algorithms (EAs) have still not been massively adopted as part of a general "problem-solving toolkit". We think that one of the main reasons for such "failure" is the lack of a clear, sensible unifying framework for the field. A proposal of a solution for this state of affairs gave birth to GUIDE.
There are (at least) two reasons for confusion among general users: first, until the publication of two books, one by Michalewicz [2] and the other by Eiben and Smith [3], it was very difficult to get a clear picture of the EC field, as there was not even a common terminology between papers in the domain. This terminology is very influenced by the history of the models that have been proposed over the years and, even though all models share a common structure, no existing software package allows the user to actually shift from one model to another [4].
The second problem is related to the specific tuning of this kind of algorithms. The description of a specific EA contains its components (the choice of representation, selection, recombination, and mutation operators) thereby setting a framework, while still leaving quite a few items undefined [5]. For instance, in a simple Genetic Algorithm (GA), while the representation is a simple bitstring with its associated operators, further details have to be given (population size and probability of application of these operators) before having a running version of the algorithm. These data, called the algorithm parameters or strategy parameters, greatly determine whether the algorithm will find an optimal or near-optimal solution, and whether it will find such a solution efficiently [5]. However, choosing such parameters is difficult, and a great deal of knowledge about EC is needed to do a sensible choice.
What would be needed for a "newcomer" to the field to use with ease an Evolutionary Algorithm? A user, advanced or not, is mainly concerned about the best possible way to solve their problem, so the historical differences that exist in the terminology will not matter at this stage [4]. Rather, as they are trying to solve a problem, they have the knowledge about two important points: first, they should be able to decide on an encoding for their problem. In other words, the problem to be solved needs to be adequately represented. Second, they have to somehow encode and define what is a good solution for their problem: this is what is called the definition of the fitness function. Other than that, they shouldn't be concerned with any of the details that we, practitioners in the field of EC, have to know about. GUIDE provides such a facility.
In this document you will find the description of GUIDE, from a designer's point of view. Writing this document was a great opportunity for us to revisit design choices we took for the implementation, so ideas and hints for improving them are added on the margins
(like the one you see here), or as footnotes2. This document contains two big parts: one explaining the basis of GUIDE: it is what we called the kernel, and it is presented in Chapter  . The GUI based on that kernel is in Chapter  .


1  How to use this guide
    1.1  Purpose and Audience
    1.2  Scope
    1.3  Suggested Reading Order
    1.4  Notational Conventions
    1.5  Associated Documents and Electronic Resources
2  The kernel of GUIDE
    2.1  Main classes description
        2.1.1  Evolutionary Algorithm Class
        2.1.2  Evolutionary Engine: EvolutionEngine class
        2.1.3  Fitness Function: the FitnessFunction class
        2.1.4  Representation of a problem in an EA
        2.1.5  Type
        2.1.6  Variable
        2.1.7  GeneDefinition
        2.1.8  Gene
        2.1.9  Genome
    2.2  Code Generation
    2.3  A Complete Example
3  The GUI in GUIDE
4  TODO's
    4.1  On this Document
    4.2  On the implementation of GUIDE

List of Figures

    2.1  GUIDE as a layer
    2.2  Types, Genes, and others.
    2.3  GUIDE: two ways of generating an EA
    2.4  The engine and the controler idea

List of Tables

    2.1  XML Structure of an EA
    2.2  XML Structure of an Evolution Engine (EE)
    2.3  XML Structure of a Fitness Function
    2.4  Defining a Basic Type and its Translation
    2.5  Parameters Definition Example
    2.6  Example of the XML Representation for Type enumeration
    2.7  Parameters Definition Example
    2.8  Directory Structure for Types Plug and Play
    2.9  Directory Structure for a Type
    2.10  GeneDefinition XML Representation
    2.11  Directory Structure for a Type
    2.12  XML Structure of an EA

Chapter 1
How to use this guide

1.1  Purpose and Audience

This document is targeted to any user that wishes to understand the internal functioning of GUIDE.

1.2  Scope

1.3  Suggested Reading Order

This document is organized in a logical understanding order: we will explain what is our view of an evolutionary algorithm at the beginning of the document, and then proceed examining the different parts needed to present this view to an user. So the best way of reading this document is to follow the logical structure. However, the different parts been presented are also differentiated by Sections, contained in 2 main Chapters: chap. 2 explains the kernel of the application, and chap. 3 explains the Graphical User Interface associated with this kernel.

1.4  Notational Conventions

In general, the following conventions are used in this guide:

1.5  Associated Documents and Electronic Resources

GUIDE's Javadoc Documentation is in http://www.lri.fr/~ldacosta/guideDoc/ and was developped in the TAO team (http://tao.lri.fr); now is it hosted at http://gforge.inria.fr/projects/guide/. There are 2 main papers, to this date, associated with it: the first was published in 2003, under the title GUIDE: Unifying Evolutionary Engines through a Graphical User Interface, written by Pierre Collet and Marc Schoenauer [4]. The second is currently being evaluated for publication in the Journal of Artificial Intelligence Tools, and is identified in the biliography as [1].
GUIDE generates code for two evolutionary libraries: EO and ECJ. EO's website is http://eodev.sourceforge.net/ and a main communication describing its functioning was published by Keizer et al. and corresponds to reference [6]. ECJ's website is http://www.cs.gmu.edu/~eclab/projects/ecj/
GUIDE is actively used as product in the Evotest European Project http://evotest.iti.upv.es/

Chapter 2
The kernel of GUIDE

GUIDE implements an abstraction layer for the user (or for the application3) that wants to use a meta-heuristic as means of finding a solution (for a more detailed explanation, please see [4] and [1]). It uses a description language (see [7] for details) for choosing the basic types and associated initialization and variation operators, and fully implementing the different types of representation-independent operators.
GUIDE currently implements an interface towards 2 evolutionary libraries4: EO [6] and ECJ [8] (Evolutionary Computation in Java). As a good layer, the users of the layer above do not need to know about this!! See (Fig. 2.1)
Figure 2.1: GUIDE as a layer

2.1  Main classes description

As an user is interested in developing an EA to solve its problem, the interaction presented in GUIDE will be with such an object. The description of the fonctioning of the system in this document will start by describing what is an EA.
For all class we five the Java fully qualified name and its JavaDoc documentation location, relative to a root. This root is called ROOTDOC, and currently it is on http://www.lri.fr/~ldacosta/guideDoc

2.1.1  Evolutionary Algorithm Class

This class contains the description of what en Evolutionary Algorithm (EA) is. As such, it has 3 private attributes describing the principal parts: an Evolutionary Engine (EE, described in 2.1.2), the Representation of the problem (described in 2.1.4), and the Fitness Function (described in 2.1.3). By the fact that it knows when the structure has changed, this class can offer advice as whether the code for this class should be generated, or is already up-to-date.
An EA is fully described by an XML Document, that has the structure shown in Table 2.1.
<!--Instance saved on [2008/03/15 18:41:30]-->
	    .....evolutionary engine description..... 
	    .....representation description..... 
  <EVAL_FUNCTION nbHelpLines="1">
	    .....evaluation function description..... 

Table 2.1: XML Structure of an EA
Each one of the 3 sections correspond to the three parts of an EA. They are going to be explianed in detail next. Evolutionary Engine (EE, described in 2.1.2), the Representation of the problem (described in 2.1.4), and the Fitness Function (described in 2.1.3).

2.1.2  Evolutionary Engine: EvolutionEngine class

The Evolution Engine (EE) of an EA contains the parameters of the engine shared by any kind of algorithm. They are described by an XML file (see Table 2.2)
    <NUM_GEN activated="true">500</NUM_GEN>
    <NUM_EVAL activated="false">1</NUM_EVAL>
    <MAX_TIME activated="false">1</MAX_TIME>
    <ENGINE>SteadyState GA</ENGINE>
    <ELITE TYPE="perc">15</ELITE>
    <FERTIL TYPE="perc">85</FERTIL>
    <NB_GEN TYPE="perc">100</NB_GEN>
    <GEN_SEL PARAM="2.0">Tournam.</GEN_SEL>
    <NB_OFFSPR TYPE="perc">100</NB_OFFSPR>
    <FINAL_RED PARAM="2.0">Sequent.</FINAL_RED>

Table 2.2: XML Structure of an Evolution Engine (EE)
Each one of the tags of the XML file represents one parameter of the engine. These are all encapsulated in class guide.kernel.EvolutionEngine, who then provides methods to access and set the information. An explanation of the parameters is given here:
  1. General Parameters:
  2. Initial Population Parameters:
  3. Intermediate Population Parameters:
  4. Final Population Parameters:
Selectors implemented in GUIDE  
A description of the Selectors implemented in GUIDE is given here. For a very interesting and detailed study of selection procedures, please see the work of Bäck [9]. For each Selection method we give the constant that represents it and its string descriptor (used in between the XML tags on the file description). All constants are defined in guide.kernel.Util.EvolutionSelectionConstants
  1. Roulette Wheel. Represented in GUIDE by the constant EvolutionSelectionConstants.ROULETTE_WHEEL. String descriptor: "Roul. Wh."
    Also called Proportional Selection, this method was introduced by Holland for the Genetic Algorithm [10]. It assigns selection probabilites according to the relative fitness of individuals:
    pi = F(ai)


  2. (Linear) Ranking. Represented in GUIDE by the constant RANKING. String descriptor: "Ranking"
    Defined by Baker [11], it uses a linear function to map indices i to selection probabilities pi. Assuming that individuals are sorted according to their fitness, the selection probabilities are given by
    pi =
    h+ - (h+ - h-) * i - 1

    l- 1

    The couple (h-,h+) define the slope of the linear function. However, notice that the constraint j=1lpi = 1 requires that 1 h+ 2 and h- = 2 - h+. So Eq. 2.2 can be rewritten as in Eq. 2.3.
    pi =
    h+ - 2 * (h+ - 1) * i - 1

    l- 1

    It is common to use a value of h+ = 1.1. This is the value that GUIDE asks as a parameter of this Selector.
  3. Deterministic Tournament: Represented in GUIDE by the constant TOURNAMENT. String descriptor: "Tournam."
    This selector chooses an individual by selecting a number q ( 2) of individuals at random and selecting the best one. q is usually 2, but can be configured in GUIDE.
  4. Stochastic Tournament. Represented in GUIDE by the constant STOCHASTIC_TOURNAMENT. String descriptor: "Stoch. Trn."
    This selector behaves similarly of Deterministic Tournament. Stochastic Tournament of rate R first choses two individuals from the population, and selects the best one with probability R (the worse one with probability 1-R). Real parameter R should be in [0.5,1].
  5. Random: Represented in GUIDE by the constant UNIFORM. String descriptor: "Uniform"
    This selector is the trivial one: randomly selects the individuals.
  6. Sequential: Represented in GUIDE by the constant SEQUENTIAL. String descriptor: "Sequent."
    It performs a deterministic selection, from best to wrost individuals, in turn.
Reductors implemented in GUIDE  
The way of reducing a population is implemented in GUIDE under the idea of "Reductors". Five of them are implemented: Sequential, Random, Deterministic Tournament, Stochastic Tournament and Evolution Programming Tournament. The first 4 are identical to the ones with the same name described in the Selectors explanation. The fifth (Evolution Programming Tournament) is described here.
Represented in GUIDE by the constant EP_TOURNAMENT and with a String descriptor: "E.P. Trn.", it proceeds by taking the union of the initial population with the intermediate one. For each individual a in this (double) population q individuals are chosen at random and compared with a, with respect with fitness values. This gives a new value for a, the rank of this tournament. Once all individuals have been assigned values, a deterministic algorithm chooses the survivors. GUIDE expects the application to specify the value of q. A typical value is 10.
Default Parameters  
  1. Population
    TO FINISH. Those parameters are NOT GOOD
    size = 100
  2. GUIDE assumes the problem is of type Minimization (i.e., lower fitnesses are better)
  3. the criterium stop is set at 500 generations
  4. 10 per cent of the initial population will go down directly to the final population (so elitism=.1)
  5. 85 percent of the initial pop is fertile (so the parents are chosen from there)
  6. 33 percent of the fertile population will conform the parent population. The way of choosing is by Tournament, size 2
  7. Mutation rate on parents: .1
  8. Crossover probability: .85
  9. Offspring population is 50 per cent as big in size as the parent population
  10. There is an intermediate population that is formed by the sum of 50 per cent of the offspring population, chosen by Tournament, size 2, plus 75 per cent of the non-elite population, chosen by tournament, size 2
  11. Finally, the Final population is chosen with the sum of the Elite (10 percent of the initial population), plus the rest coming from the intermediate population, chosen Sequentially.
Details about the Evolution Engine in EO can be found on http://www.lri.fr/~marc/EO/eo/tutorial/html/eoEngine.html

2.1.3  Fitness Function: the FitnessFunction class

An evaluation function provides the way of estimating the goodness of an individual in an EA. It is encapsulated by the class guide.kernel.FitnessFunction, and described by an XML file (see Table 2.3)
<?xml version="1.0" encoding="UTF-8"?>
<!--Instance saved on [2008/03/15 18:41:30]-->
  <EVAL_FUNCTION nbHelpLines="1">
       return (theGenome.var5 ? 0.75 : 0.25);

Table 2.3: XML Structure of a Fitness Function

2.1.4  Representation of a problem in an EA

In our view of an EA, the important structure to represent problems are Types (see 2.1.5). Those Types can be the base for an EA, but we also need to know how to combine them (as combination is at the base of an EA). For that, it is extended as GeneDefinition (see 2.1.7). The instantiation of a Type is a Variable (see 2.1.6), and the instantiation of a GeneDefinition is a Gene (see 2.1.8). The "top" Gene is called a Genome (see 2.1.9), who is then the actual representation of an EA. Fig. 2.2 shows what we mean.

Figure 2.2: Types, Genes, and others.

2.1.5  Type

Being a Type one of the most important part of GUIDE, we will describe in quite some detail5 the choices taken for its implementation.

Basic and Container Types

A Type can be either Basic or Container; it is "basic" when it represents a type present in the underlying programming language6. It is "container" if other types are needed to completely define it. In other words, if it contains other types.

Parameters for Types

For completely defining a type we usually have to set some properties about it. For example, a Vector type needs a size; or we may be interested in assigning an interval of definition for an Integer (say (-, 34]). This parameters management is done with the internally defined enumeration type called BasicTypesForParams7. The structure looks like this:
	public static enum BasicTypesForParams {

So every time has a list of parameters, with names associated (mParamsNames), for each param, its type (mParamsTypes) and an explanation (mExplanations). An example is given in Table 2.5

Let's take the instance of class guide.kernel.Type that represents a Floating-point precision numerical type is a Basic Numeric type.It has a parameter of type Interval (BasicTypesForParams.REALINTERVAL). So
mParamsNames[0] = "Interval";
mParamsTypes[0] = BasicTypesForParams.REALINTERVAL;
and mExplanations[0] = "Interval of Definition";
The value taken by this interval is defined on the instanced Variable (see 2.1.6 and Example 2.7).

Table 2.5: Parameters Definition Example

Defining a Type

The main motivation for keeping all definition of a Type in an unique class (instead of doing a hierarchy of Types) is that now an XML representation can be defined for any Type we want to. It is quite straightforward to do so, and an example is given in Table 2.6.
<?xml version="1.0" encoding="UTF-8"?>
    <PARAM type="intinterval">bounds</PARAM>
    <LINE>Enumerate : can take chosen values only</LINE>
    <LINE>Parameters: nominal values</LINE>

Table 2.6: Example of the XML Representation for Type enumeration
This has one important consequence: any system that uses the class guide.kernel.Type for Type use can offer its users the possibility of dynamically defining Types: they only have to specify where the Type definitions are, and provide them. So any type can be used in this system. That is the philosophy behing Types management in GUIDE.

2.1.6  Variable

A object of type guide.kernel.Variable is an object whose definition is determined by an accompanying object of type instantiation of a guide.kernel.Type. It basically controls the specific values a Type has. For Basic types, just with this value it will be enough (for example, we may want to model a variable, type int, that takes a value of 3). But for Container types, we will also need to know who are our Children (Container Types have children, so they have to know what are the values of these children).
For anyone, we need to know who is my parent and what are the values of the parameters (defined in the Type. See 2.1.5).

(coming from Example 2.5)
Let's take the instance of class guide.kernel.Type that represents a Floating-point precision numerical type is a Basic Numeric type.It has a parameter of type Interval (BasicTypesForParams.REALINTERVAL). The value taken by this interval is defined as a Value that can be [-3.82, 34.1]

Table 2.7: Parameters Definition Example

2.1.7  GeneDefinition

A GeneDefinition is a guide.kernel.Type that has Operators for mutation and recombination. In other words, it is just a type that can be combined with others like him. That is why you basically see, in the JavaDoc documentation, methods to access those variation operators. WHERE exactly those operators are defined is given by a location where all the types are kept:TYPESLOC. the directory has a particular structure where the types' definitions are present, and also the variation operators that can be applied to them. The detail of that structure is on Table 2.8. We will examine it in detail next.
all types here
Table 2.8: Directory Structure for Types Plug and Play
As seen in Table 2.8, there is an important file in the directory: operatorSchema.xml, which contains the grammar definition of the operators for each gene definition. We will come back to the operators later
Ref. to operators Section
. Additionally, the definition for a specific type (including its operators) are at TYPESLOC /name of the type. This definition is shown in Table 2.9 .
< type-name > /
Table 2.9: Directory Structure for a Type
deftype.xml contains the definition for the Type that "defines" this GeneDefinition. Its structure follows the one presented at page pageref, specifically on Table 2.6. defgene.xml defines specifically the GeneDefinition, and has exactly the same information as a Type, with an added reference to the definitions of Operators. See Table 2.10.
<?xml version="1.0" encoding="UTF-8"?>
     ..... type definition here....    

Table 2.10: GeneDefinition XML Representation
The structure of a GeneDefinition presented in Table 2.10 means that we can recover its definition, knowing from what Type it coms from, and where are the definitions for its Operators. This is used in GUIDE to recuperate information that may have been damaged or lost .
Each type of variation operators (crossover, mutation and initialization) are represented by a directory with actual definitions (i.e., code). There can be several operators to be applied for each type (i.e., several crossover operators for an int, for example). The definition are language-dependent, so they are separated by evolutionary libraries, with the actual code for it. See Table 2.11
file 1.xml
Table 2.11: Directory Structure for a Type

2.1.8  Gene

In the same way that a guide.kernel.Variable is the encapsulation of a value for guide.kernel.Type, guide.kernel.genome.Gene is the encapsulation of guide.kernel.genome.GeneDefinition. It manages the specific Operators that apply on this Gene.

2.1.9  Genome

The Genome is the representation of the problem. It is, in fact, just a Gene defined as a type Tuple - in that way, it accepts any combination of Types and Genes that the user may want.

2.2  Code Generation

The idea  
GUIDE can be used to generate an EA to be run by itself ("standalone") or it can also be used to produce an evolution engine to solve a problem as part of another application (see Fig. 2.3). As such, we need a centralized code generation scheme offering this flexibility.
Figure 2.3: GUIDE: two ways of generating an EA
The more straightforward way of reaching this goal is by considering a standalone EA as a special type of engine: one that is run by a special application, i.e., the end-user itself. GUIDE always generates an engine, that needs to be "controled" (i.e., started, stopped, paused/resumed or given feedback) by another program, the controler (see Fig. 2.4).
Figure 2.4: The engine and the controler idea
Under this scheme, the engine provides 2 things: (1) all the logic and important code to execute the generated EA, and (2) a way of creating itself. The controler has to create the engine, and to start it. On demand, it provides the fitness for the individuals (equivalently, population) and sends messages to the engine concerning the continuation or pausing of the execution. The important point here is that the engine gives total flexibility to the controler to perform those tasks depending on the logic of the application. A summarizing scheme of this idea is shown in Fig. 2.4
Practical implementation details.  
Implementing this idea is achieved by the following basic steps:
  1. The code representing an engine is located on a directory called src, directly under the directory of the experiment. The directory of the experiment himslef will be where the specification file for the generation of the algorithm is located. For example, if the specification for the current experiment is at
    then the code corresponding to the EA will be located at the following directory:
    and the code corresponding to the generated EA will be at:
  2. GUIDE's distribution provides two interfaces ("header files"), called IEOEngine.h IEOEngineControl.h. These two files are provided in the distribution of GUIDE, and must exist in a directory specified in the settings file, under the tag DIR on INCLUDES8
  3. The controler (see Fig. 2.4 for a quick reminder of what is a Controler):
    1. A general, abstract implementation of a Controler is generated by GUIDE at code-generation time: it is on the file GUIDEGenericEngineControl.h, on the source directory of the EA.
    2. The user (equivalently, application) must provide a specific implementation of a Controler. An example of a Controler is provided with GUIDE's distribution: an user can modify it to make it suitable for their needs. It must be kept in the directory specified in the settings file, under the tag CONTROLERDIR (see footnote 6)
  4. Any other classes needed by the engine should be specified in the directory of the settings file identified by the tag DIR on EXTRACODE (see footnote 6)
An example  
Here I put the example that is in GUIDEKernel (for Evotest)
GUIDE provides pre-defined types
The representation of an EA
The representation of an EA is encapsulated in class guide.kernel.Genome. A Genome is, in fact, a special class of Gene; the important point is that a Genome is a Gene that contains other Genes, and that do not have a parent. Let's begin by explaining what a Gene is: we will need for that the class Type!!
described by an XML file (see Table 2.12)
<?xml version="1.0" encoding="UTF-8"?>
    <INITIALISATOR id="init_root_default" name="default" type="root" userdefined="no" varname="theGenome" />
    <INITIALISATOR id="init_bool_false" name="false" type="bool" userdefined="no" varname="var5" />
    <MUTATOR id="mut_root_default" name="default" type="root" userdefined="no" varname="theGenome" />
    <MUTATOR id="mut_bool_flip" name="flip" type="bool" userdefined="no" varname="var5" />
    <CROSSOVER id="cross_root_default" name="default" type="root" userdefined="no" varname="theGenome" />
    <CROSSOVER id="cross_bool_exchange" name="exchange" type="bool" userdefined="no" varname="var5" />
    <CHROMOSOME name="theGenome" type="root">
      <CHROMO_INITIALISATOR id="init_root_default" weight="1.0" />
      <CHROMO_MUTATOR id="mut_root_default" weight="1.0" />
      <CHROMO_CROSSOVER id="cross_root_default" weight="1.0" />
      <CHROMOSOME name="var5" type="bool">
        <CHROMO_INITIALISATOR id="init_bool_false" weight="1.0" />
        <CHROMO_MUTATOR id="mut_bool_flip" weight="1.0" />
        <CHROMO_CROSSOVER id="cross_bool_exchange" weight="1.0" />

Table 2.12: XML Structure of an EA

2.3  A Complete Example

Chapter 3

Chapter 4

4.1  On this Document

4.2  On the implementation of GUIDE


To the people that worked before?? Pierre Collet for GUIDE.
Funding information may also be included here.


Marc Schoenauer and Luis Da Costa. Representation-independent evolutionary algorithms: Principles and GUIDE, 2008. Submitted to the Journal of Artificial Intelligence Tools, March 2008.
Z. Michalewicz. Genetic Algorithms + Data Structures = Evolution Programs. Springer Verlag, New-York, 1992-1996. 1st-3rd edition.
A.E. Eiben and J.E. Smith. Introduction to Evolutionary Computing. Springer Verlag, 2003.
Pierre Collet and Marc Schoenauer. GUIDE: Unifying evolutionary engines through a graphical user interface. In Pierre Liardet, Pierre Collet, Cyril Fonlupt, Evelyne Lutton, and Marc Schoenauer, editors, Evolution Artificielle, 6th International Conference, volume 2936 of Lecture Notes in Computer Science, pages 203-215, Marseilles, France, 27-30 October 2003. Springer. Revised Selected Papers.
A. E. Eiben, Z. Michalewicz, M. Schoenauer, and J. E. Smith. Parameter Control in Evolutionary Algorithms. In F.G. Lobo, C.F. Lima, and Z. Michalewicz, editors, Parameter Setting in Evolutionary Algorithms, chapter 2, pages 19-46. Springer Verlag, 2007.
M. Keijzer, J. J. Merelo, G. Romero, and M. Schoenauer. Evolving Objects: a general purpose evolutionary computation library. In P. Collet et al., editor, Evolution Artificielle'01, pages 229-241. LNCS 2310, Springer Verlag, 2002. URL: http://eodev.sourceforge.net/.
L. Da Costa. Specification of language description. Technical Report EU-IST STREP FP6-IST-2006-33472 EvoTest, INRIA, 2007.
Sean Luke, Liviu Panait, Gabriel Balan, Sean Paus, Zbigniew Skolicki, Jeff Bassett, and Robert Hubley. ECJ: Evolutionary computation in java.
Thomas Bäck. Selective pressure in evolutionary algorithms: A characterization of selection mechanisms, 1994.
J. H. Holland. Adaptation in Natural and Artificial Systems. University of Michigan Press, Ann Arbor, 1975.
J. E. Baker. Adaptive selection methods for genetic algorithms. In J. J. Grefenstette, editor, Proc. of the 1st International Conference on genetic Algorithms and Their Applications, pages 101-111, Hillsdale, NJ, 1985. Lawrence Erlbaum Associates.


1Latest GUIDE paper was sent on March 2008.
2This is a footnote - just in case you had forgotten.
3In this document we will use the term GUIDE's user to refer to an actual person, or to an application using GUIDE
4The reasons for such a choice are described in [1]
5For basic description of the names of the methods and of the internal/external attributes, please consult the JavaDoc documentation.
6There is an implicit assumption here: programming languages provide roughly the same types. I am not so sure this is a fair assumption... Think, for example, of the distinction between Matlab and C++. Or Lisp and Java?
7Obviously, this sucks big time. Big TODO here. A parameter should be a Type, and then the actual value of that should be a Variable. The problem with that is that an Interval is NOT a Type... But this should be resolved, it is not THAT hard, I think...
8If this last sentence is confusing to you, or you would like more details, please refer to the Installation Manual, found in http://gforge.inria.fr/projects/guide/, Tab Docs, and here http://www.lri.fr/~ldacosta/guide/installation/GUIDEInstallationManual.html

File translated from TEX by TTH, version 3.80.
On 27 Mar 2008, 16:59.