**3.1. Linear sequence of instructions**

In LGP a program is composed of a linear sequence of imperative instructions (see [6] for more details). Each instruction is typically 3-register instruction. That means that every instruction includes an operation on two operand registers, one of them could be holding a constant value, and then assigns the result to a third register:

$$r\_i = \begin{cases} r\_j \text{ op } (r\_k|c\_k) \\ (r\_j|c\_j) \text{ op } r\_k \end{cases}$$

where *op* is the operation symbol, *ri* is the destination register, *rj*, *rk* are calculation registers (or operands) and *cj*, *ck* are constant registers (only one constant register is allowed per instruction).

On the implementation level of standard LGP, each imperative instruction is represented by a list of four integer values where the first value gives the operator and the three next values represent the three register indices. For instance, an instruction like *ri* = *rj* × *rk* is stored as a quadruple < ×, *i*, *j*, *k* >, which in turn is coded as four indices indicating respectively the operation number in the set of possible operations, and 3 indices in the set of possible registers (and/or constant registers). Of course, even if the programming language is basically a 3-register instruction language, it is possible to ignore the last index in order to include 2-register instructions like *ri* = sin(*rk*).

Instructions are executed by a virtual machine using floating-point value registers to perform the computations required by the program. The problem inputs are stored in a set of registers. Typically the program output is read in a dedicated register (usually named *r*0) at the end of the program execution. These input and output registers are read-write and can serve for intermediate calculations. Usually, additional read-only registers store user defined constants, and extra read-write registers can be added to allow for complex calculations. The use of several calculation registers makes possible a number of different program paths, as explained in [6] and in [28].

### **3.2. Mapping a float vector to a linear program**

Here we explain how a float vector (i.e. an individual of the population), evolved by either DE or CMA-ES, is translated to a linear program in the LGP form.

As explained in the previous section, we need 4 indices to code for the operation number and 3 registers involved. Thus we split the float vector individual into consecutive sequences of 4 floats < *v*1, *v*2, *v*3, *v*<sup>4</sup> >, where *v*<sup>1</sup> encodes the operator number, and *v*2, *v*3, *v*<sup>4</sup> encode the destination and operand registers. In order to convert a float *vi* into an integer index, we apply one of the following computations:

• Conversion of the operator index:

8 Will-be-set-by-IN-TECH

• CMA-LEP, for Covariance Matrix Adaption Linear Evolutionary Programming, when the

First we recall the basis of linear programs encoding, and execution, and then we explain the mapping process from continuous representation to imperative instructions. We conclude with some remarks on the integration of this representation and mapping with the DE and

In LGP a program is composed of a linear sequence of imperative instructions (see [6] for more details). Each instruction is typically 3-register instruction. That means that every instruction includes an operation on two operand registers, one of them could be holding a constant

> *rj* op (*rk*|*ck*) (*rj*|*cj*) op *rk*

where *op* is the operation symbol, *ri* is the destination register, *rj*, *rk* are calculation registers (or operands) and *cj*, *ck* are constant registers (only one constant register is allowed per

On the implementation level of standard LGP, each imperative instruction is represented by a list of four integer values where the first value gives the operator and the three next values represent the three register indices. For instance, an instruction like *ri* = *rj* × *rk* is stored as a quadruple < ×, *i*, *j*, *k* >, which in turn is coded as four indices indicating respectively the operation number in the set of possible operations, and 3 indices in the set of possible registers (and/or constant registers). Of course, even if the programming language is basically a 3-register instruction language, it is possible to ignore the last index in order to include

Instructions are executed by a virtual machine using floating-point value registers to perform the computations required by the program. The problem inputs are stored in a set of registers. Typically the program output is read in a dedicated register (usually named *r*0) at the end of the program execution. These input and output registers are read-write and can serve for intermediate calculations. Usually, additional read-only registers store user defined constants, and extra read-write registers can be added to allow for complex calculations. The use of several calculation registers makes possible a number of different program paths, as explained

Here we explain how a float vector (i.e. an individual of the population), evolved by either

As explained in the previous section, we need 4 indices to code for the operation number and 3 registers involved. Thus we split the float vector individual into consecutive sequences of 4 floats < *v*1, *v*2, *v*3, *v*<sup>4</sup> >, where *v*<sup>1</sup> encodes the operator number, and *v*2, *v*3, *v*<sup>4</sup> encode the

*ri* =

evolutionary engine is CMA-ES.

**3.1. Linear sequence of instructions**

2-register instructions like *ri* = sin(*rk*).

**3.2. Mapping a float vector to a linear program**

DE or CMA-ES, is translated to a linear program in the LGP form.

value, and then assigns the result to a third register:

CMA-ES engines.

instruction).

in [6] and in [28].

$$\#\text{operator} = \lfloor (v\_i - \lfloor v\_i \rfloor) \times n\_{\text{operators}} \rfloor \tag{6}$$

where *n*operators denotes the number of possible operators.

• Conversion of the destination register index:

$$\text{\#registor} = \lfloor (v\_i - \lfloor v\_i \rfloor) \times n\_{\text{registers}} \rfloor \tag{7}$$

where *n*registers denotes the number of possible read-write registers.

• The conversion of an operand register depends whether it is a constant or a read-write register. This is controlled by a user defined probability of selecting constant registers, denoted *PC* in the following equation:

$$\begin{cases} \text{\# read-write register} = \lfloor (\frac{v\_{i} - \lfloor v\_{i} \rfloor - P\_{c}}{1 - P\_{c}}) \times n\_{\text{registers}} \rfloor \text{ if } (v\_{i} - \lfloor v\_{i} \rfloor) > P\_{\text{C}}\\ \text{\# constant register} = \lfloor v\_{i} \rfloor \text{mod } n\_{\text{consants}} & \text{otherwise} \end{cases} \tag{8}$$

where *n*registers denotes the number of possible read-write registers, and *n*constants denotes the number of possible constant registers.

#### *Example of a mapping process*

Let us suppose we work with 6 read-write registers (*r*<sup>0</sup> to *r*5), 50 constant registers, and the 4 following operators:

$$\begin{array}{ccc} \begin{array}{c} \text{0} : \text{ } \end{array} & \begin{array}{c} \text{-} : \text{ } \end{array} & \begin{array}{c} \text{-} : \text{ } \end{array} \end{array}$$

We set up the constant register probability to *PC* = 0.1 and we consider the following vector composed of 8 floats, to be translated into 2 imperative instructions (< *v*1, *v*2, *v*3, *v*<sup>4</sup> > and < *v*5, *v*6, *v*7, *v*<sup>8</sup> >):

$$\frac{v\_1 \quad v\_2 \quad v\_3 \quad v\_4 \quad v\_5 \quad v\_6 \quad v\_7 \quad v\_8}{0.17 \mid 2.41 \mid 1.86 \mid 3.07 \mid 0.65 \mid 1.15 \mid 1.25 \mid 4.28}$$

Value *v*<sup>1</sup> denotes one operator among the four to choose from. Applying Eq. 6, we get #operator = �(0.17 − �0.17�) × 4� = 0, meaning that the first operator is +.

The second value *v*<sup>2</sup> = 2.41 is turned into a destination register. According to Eq. 7, we obtain #register = �(2.41 − �2.41�) × 6� = �2.46� = 2, meaning that the destination register is *r*2.

The next value *v*<sup>3</sup> = 1.86 gives an operand register. According to Eq. 8, it is a read-write register since (1.86 − �1.86�) = 0.86 > *PC*. Thus the first operand register is: #register = �((1.86 − �1.86� − 0.1)/0.9) × 6� = �5.07� = 5, meaning read-write register *r*5.

The last of the four first operands is decoded as a constant register since (3.07 − �3.07�) = 0.07 ≤ *PC*. The index is �3.07� mod 50 = 3, meaning constant register *c*3.

#### 10 Will-be-set-by-IN-TECH 36 Genetic Programming – New Approaches and Successful Applications Continuous Schemes for Program Evolution <sup>11</sup>

So the 4 first values of the genotype are translated as:

$$r\_2 = r\_5 + c\_3$$

Heuristic Problem Pop. Ind. size # eval. extra params LDEP Regressions 20 128 5E4 *F* = 0.5, *CR* = 0.1

**Table 1.** Main experimental parameters

from one generation to the next.

CMA-LEP and GP.

CMA-LEP and GP.

**4.1. Symbolic regression problems**

<sup>1</sup> http://cs.gmu.edu/~eclab/projects/ecj/ <sup>2</sup> http://www.lri.fr/~hansen/cmaes\_inmatlab.html

**4. Experiments**

parameters.

choices:

Ant 30 50 2E5 *F* = 0.5, *CR* = 0.1 CMA-LEP Regressions 20 128 5E4 *σ* ∈ {1, 10}, *λ* ∈ {10, 100},

GP Regressions 1000 N.A. 5E4 Elitism, max Depth=11,

Ant 30 50 2E5 *σ* ∈ {1, 10}, *λ* ∈ {10, 100}

Ant 4000 N.A. 2E5 Elitism, max Depth=11,

artificial ant), and we also add two regression problems that include float constants.

• We run all standard GP experiments using the well-known ECJ library1.

• For TreeDE we take the results as they are reported in [17]:

We use the same benchmark problems as in [17] (4 symbolic regressions and the Santa Fe

Before listing our experimental parameters in Table 1, we explain some of our implementation

• For GP we use a maximum generation number of 50 and set the population size in accordance with the maximum number of evaluations. We keep the best (elite) individual

• We use the publicly available C language version of CMA-ES2, with overall default

• For regression, 1500 iterations on a population of 20 vectors were allowed, and runs were done for every tree depth in the range {1, . . . , 10}. It thus amounts to a total of 300, 000 evaluations. Among these runs, reference [17] reported only those associated to the tree depth that obtained the best result (which may well imply a favorable bias, in our opinion). As we could not apply this notion of best tree depth in our heuristic, we decided as a trade-off to allow 50, 000 evaluations for regression with both LDEP,

• For the Santa Fe Trail artificial ant problem, the same calculation gives a total of 450, 000 evaluations for TreeDE. We decided for a trade-off of 200, 000 evaluations for LDEP,

The aim of these 1-dimensional symbolic regression problems is to find some symbolic mathematical expression (or program) that best approximates a target function that is known only by a set of examples, or fitness cases, (*xk*, *f*(*xk*)). In our case, 20 values *xk* are chosen evenly distributed in the range [−1.0, +1.0]. The evaluation of programs (or *fitness*

80% Xover, 10% Mut, 10% Copy

Continuous Schemes for Program Evolution 37

80% Xover, 10% Mut, 10% Copy

The mapping process continues with the four next values, until we are left with the following program:

$$r\_2 = r\_5 + c\_3$$

$$r\_0 = r\_1 \times r\_1$$
