Circular Buer { Given Modulus Increment

Whilst the \shuer" solution is an entirely correct solution to the queue problem, it is a very rare one (in that it was found only once in 379 runs). The experiments in this section are designed to test the feasibility of evolving circular queue implementations with the tness function when given primitives which perform the appropriate increment oper- ations. The \modulus increment" (MIncn) terminals correspond to inc aux and dec aux used in the stack experiments (cf. Section 3.3.2). They take the value of the corresponding auxiliary variable, increase it by one, reduce it modulo max (i.e. 10) and store the new value back into the auxiliary variable (cf. Table 4.3). The complete parameters are given in Table 4.7, and Table 4.8 contains all the changes between these experiments and those that produced the Shuer solution.

In one set of runs of the 11 runs that completed, 5 produced solutions which passed the whole test case (another 7 aborted due to run time constraints). Figure 4.9 shows the simplest. This program can be simplied to Figure 4.10 using the facts that in this program aux3 is always 1 and noting that for these test sequences twice the next item to be dequeued (i.e. the front of the queue) is always an address outside the used part of the index memory and so is always zero. (In the runs described in this section, reading outside the indexed memory returns zero rather than aborting the program).

The probability of a successful run

P

(104

42) is estimated as 5

=

11, i.e. 5 successes

in 11 trials. (A pessimistic estimate includes all the runs and assumes the runs which ran out of time would have failed, i.e.

P

(104

42) = 5

=

18). Using Equation 3.1 (Section

3.6.1) the number of runs required to be assured (to within probability 1%) of obtaining at least one solution is 8 (pessimistically 15). This requires 810

00042 = 3

360

000

Table 4.6: Number of each the ve queue operations used in the tness test case for each length of queue. (Test case used in experiments where \Modulus Increment" was provided and where it was evolved).

Queue length makenull front dequeue enqueue empty Totals

undened 5 5 0 10 27 16 53 1 4 9 14 18 7 52 2 4 12 11 8 7 42 3 9 6 7 5 27 4 4 6 11 21 5 4 11 9 3 27 6 8 9 11 5 33 7 10 11 9 3 33 8 3 9 4 16 9 5 4 2 11 Totals 23 64 81 104 48 320 aux1 aux1 Tail 0 1 2 3 3 5 6 7 8 9 10 enqueue Head aux2 aux2 0 0 dequeue front 0 0 0

Figure 4.8: Execution of \Modulus Increment" program. Data are enqueued in front of cell indicated by aux1 and dequeued from cell in front of that indicated by aux2. Labels in bold indicate current values, dotted show previous values.

Table 4.7: Tableau for Evolving a Queue: Given Modulus Increment Primitives Objective To evolve a rst-in rst-out queue

Architecture Five separate trees, plus single ADF

Primitives makenull +, ;, 0, 1, max, mod, PROG2, QROG2, aux1, aux2,

aux3, Set Aux1, Set Aux2, Set Aux3, Inc Aux1, MInc1, Inc Aux2, MInc2, Inc Aux3, MInc3, Dec Aux3, read, write, Adf1

front +, ;, 0, 1, max, mod, PROG2, QROG2, aux1, aux2,

aux3, read, Adf1

dequeue +, ;, 0, 1, max, mod, PROG2, QROG2, aux1, aux2,

aux3, Inc Aux1, MInc1, Inc Aux2, MInc2, Inc Aux3, MInc3, Dec Aux3, Adf1 read, write, Adf1, Front

enqueue +, ;, 0, 1, max, mod, PROG2, QROG2, aux1, aux2,

aux3, Inc Aux1, MInc1, Inc Aux2, MInc2, Inc Aux3, MInc3, Dec Aux3, read, write, Adf1, arg1

empty +, ;, 0, 1, max, mod, PROG2, QROG2, aux1, aux2,

aux3, read, Adf1

adf1 +, ;, 0, 1, max, mod, PROG2, QROG2, arg1

Fitness Case 4 test sequences of 40 tests and one of 160 (Table 4.6). Values en- queued as Table 4.9 except F = 15.7 rather than 5.0

No program aborts

Fitness Scaling Pareto comparison with each operation and a memory penalty con- tributing separately. Operations score 1 per test passed and each memory cell used (above 15) scores;1.

Selection Pareto tournament of 4

Hits No. tests passed

Wrapper makenull result ignored

front no wrapper

dequeue no wrapper enqueue result ignored

empty result = 0) TRUE, otherwise FALSE

adf1 n/a

Parameters Population = 10,000, G=50, program size 250

read ADD aux3 aux2 read ADD aux3 aux2 read ADD ADD front SUB aux2 aux3 QROG2 aux3 max PROG2 aux2 PROG2 aux2 0 mod aux1 SUB PROG2 empty makenull read PROG2 Set_Aux1 0 Set_Aux1 Set_Aux1 Set_Aux3 Set_Aux2 Set_Aux1 0 MInc3 PROG2 write Minc1 arg1 enqueue QROG2 write 0 MInc2 0 dequeue QROG2 arg1 max adf1 aux2 aux3 ADD read

Figure 4.9: \Modulus Increment" Program

read ADD aux2 1 front PROG2 Set_Aux1 0 PROG2 Set_Aux2 0 Set_Aux3 1 makenull MInc2 read dequeue write Minc1 arg1 enqueue aux1 SUB aux2 empty

Table 4.8: Changes between Shuer experiment and evolving a queue given MIncn The six trees that form each program were split into various categories:

those that initialise things (makenull)

those that change the queue (makenull, dequeue, enqueue), subroutines (adf1).

Using these categories the primitives were restricted to particular trees:

Set Auxn can only be used by makenull

The primitives which change things (write, Inc Auxn, Dec Auxn, MInc Auxn) can

only appear in tree where change is expected

Allow arg1 only in trees which have arguments, i.e. enqueue and adf1.

adf1 contains only primitives which perform calculations (+,;, max, mod, PROG2,

QROG2). I.e. do not have side eects.

dequeue can call front

Add a third variable Aux3 and associated primitives (i.e. Set Aux3, Inc Aux3 and MInc3). Add PROG2 and QROG2. dequeue requires two actions to be performed (return result and remove item from queue), QROG2 naturally allows this and allows the rst action to be the one yielding the overall result.

Dec Aux1 and Dec Aux2 are removed. By removing decrement it was hoped to avoid clashes when crossing over between similar programs whose exact operation was incom- patible. I.e. one program causes queue head to move up one enqueue but a similar one causes it to move down and to encourage \hybrid" solutions in which:

aux3 can be used as a count of queue length as it has both increment and decrement

primitives.

Aux1 and Aux2 can still be used as head and tail pointers.

PROG2 and QROG2 can readily link together partial solutions. It had been noted

that many partial solutions used primitives (especially mod) to link together partial solutions where the primary eect of the primitive appears to be a nuisance). No memory abort

Pareto tness scaling, see Section 4.10.1

Change to 5th _{test sequence to produce a more even spread of queue lengths (Table 4.6).}

Change to range of values in the queue (by changing

F

from 31.4 to 15.7, see Section 4.8) A new individual is not inserted in the population if it is worse than the member of the population it is replacing. This change later removed, as it seemed to encourage premature convergence.

In document Genetic programming and data structures (Page 101-106)