Asynchronous Evaluation Based Genetic

Programming: Comparison of Asynchronous

and Synchronous Evaluation and Its Analysis

Tomohiro Harada1 and Keiki Takadama2

1
The University of Electro-Communications, Japan
Research Fellow of the Japan Society for the Promotion of Science DC
[email protected]
2
The University of Electro-Communications, Japan
[email protected]
http://www.cas.hc.uec.ac.jp

Abstract. This paper compares an asynchronous evaluation based GP

with a synchronous evaluation based GP to investigate the evolution abil-
ity of an asynchronous evaluation on the GP domain. As an asynchronous
evaluation based GP, this paper focuses on Tierra-based Asynchronous
GP we have proposed, which is based on a biological evolution simula-
tor, Tierra. The intensive experiment compares TAGP with simple GP
by applying them to a symbolic regression problem, and it is revealed
that an asynchronous evaluation based GP has better evolution ability
than a synchronous one.

Keywords: genetic programming, tierra, asynchronous evaluation, sym-

bolic regression.

1 Introduction
Conventional Evolutionary Algorithms (EAs) like Genetic Algorithms (GAs) [4]
and Genetic Programmings (GPs) [8] search solution by generating population
through a reproduction and a deletion based on evaluations of all individu-
als at the same time. In contrast to this, EAs such as Differential Evolution
(DE) [14], and MOEA/D [16] are recently attracted attention, and their high
search abilities have been revealed. The common feature of these approaches
is to asynchronously evolve individuals independent of other individuals, unlike
the conventional approaches requires evaluations of all other individuals.
From the viewpoint of GPs, it is assumed that the asynchronous evaluation
has advantages for the program evolution because (1) the asynchronous evalu-
ation based GP can delete incomplete programs which include infinite loops or
multiple-loops and (2) can reproduce faster executed programs which is desired
to evolve. Focusing on these advantage, the previous researches have proposed
Tierra-based Asynchronous Genetic Programming (TAGP) [5,6,11] as a novel GP
approach that asynchronously evaluates and evolves programs, which is based
on a biological evolution simulator, Tierra [12], proposed by T. S. Ray.

K. Krawiec et al. (Eds.): EuroGP 2013, LNCS 7831, pp. 241–252, 2013.

c Springer-Verlag Berlin Heidelberg 2013
242 T. Harada and K. Takadama

The purpose of this paper is to analyze the difference between the synchronous
evaluation and the asynchronous evaluation and to investigate the better evo-
lution ability of the asynchronous evaluation on the GP domain. Toward this
purpose, this paper compares TAGP as the asynchronous evaluation based GP
with simple steady-state GP (SGP) [13] as the synchronous evaluation based
GP. The experiment is conducted with the assembly language program and ap-
plies these two methods to a symbolic regression problem which is well known
and easy benchmark.
This paper is organized as follows. Section 2 discusses the difference between
the synchronous and the asynchronous evaluation EAs and clarifies the advan-
tage of the asynchronous evaluation on the GP domain. Section 3 explains a
biological evolution simulator, Tierra, which is base of TAGP, and Section 4
explains the algorithm of TAGP. Section 5 conducts an experiment to compare
TAGP with SGP and shows its result. Section 6 discusses the result and analyzes
the difference of two methods, and Section 7 finally gives conclusions and future
works.

2 Motivation

It is usual that conventional Evolutionary Algorithms (EAs) like Genetic Al-

gorithms (GAs) [4] and Genetic Programmings (GPs) [8] search solution by
generating new population through a reproduction and a deletion based on eval-
uations of all individuals in a current population. These approaches require to
evaluate all individuals before the reproduction and the deletion at the same
time, because selection is conducted based on the evaluations. Therefore, it is
necessary for the conventional EAs to synchronize evaluations of all individuals
in a population.
In contrast to this, EAs like Differential Evolution (DE) [14], and MOEA/D
[16] are recently attracted attention. The common feature of these approach
is that each individual in population independently generates a child and next
population is generated from them, unlike the conventional EAs. When gener-
ating children, evaluations of all individuals are unnecessary, and children can
be generated only based on evaluation of a focused or a few other individual(s).
From this feature, since these approaches need not synchronize evaluations of all
individuals, they can asynchronously evolve each individual.
This paper defines the former EAs as synchronous evaluation based EAs
(SEEAs), while the latter as asynchronous evaluation based EA (AEEAs). In
previous researches, it has been revealed that the AEEAs has better search abil-
ity than the SEEAs. One main reason is independent evolution of individuals.
Since evolving individual independently contributes to maintain diversity of a
population, the AEEAs can search a large area and are prevented from falling
into the local optimal. Additionally, one more advantage of the AEEAs is to
be easily able to parallelize algorithms. Since the AEEAs evolve each individual
not considering other individuals or using a part of other evaluation, they can
decrease overhead of parallelization [15] [2].
 Asynchronous Evaluation Based GP 243

As a novel GP approach which applies the asynchronous evaluation, the previ-

ous researches have proposed Tierra-based Asynchronous Genetic Programming
(TAGP) [5, 6, 11] which is based on a biological evolution simulator, Tierra [12],
proposed by T. S. Ray. The advantage to apply the asynchronous evaluation to
GP, without mentioned above, is (1) deletion of incomplete programs, and (2)
priority reproduction of faster program because of the feature of the program
evolution.
(1) Deletion of incomplete programs. When evolving programs including
loops, it is possible that programs which cannot be evaluated are generated
with genetic operators because of an infinite loop or a multiple-loop. Since
the SEEAs require all evaluations in a population to generate next popula-
tion, it is usual to restrict upper execution steps and to impose a penalty
on programs which exceed the limitation. It is, however, difficult to appro-
priately configure the restriction and the penalty. On the other hand, the
AEEAs can continue to evolve programs even if program which does not
finish its execution because all programs are independently evaluated and
programs can be reproduced without waiting for other program evaluation.
(2) Priority reproduction of faster program. In program evolution, since
programs which can be executed faster are usually evaluated better, it is ex-
pected that giving a lot of reproduction chance to such programs performs
effective. Since the AEEAs can reproduce programs in order of finishing exe-
cution, faster executed programs can be naturally given a lot of reproduction
chance.
To verify the feature and the advantage of the asynchronous evaluation in GP,
this paper compares TAGP as the AEEA with simple steady-state GP (SGP) [13]
as the SEEA.

3 Tierra
Tierra [12] proposed by T. S. Ray is a biological evolution simulator, where dig-
ital creatures are evolved through a cycle of a self-reproduction, deletion and
genetic operators such as a crossover or a mutation. Digital creatures live in
a memory space corresponding to the nature land on the earth, and they are
implemented by a linear structured computer program such as the assembly
language to reproduce (copy) themselves to a vacant memory space. CPU time
corresponding to energy like actual creatures is given to each creature, and they
execute instructions of a self-reproduction program within allocated CPU time.
Since given CPU time is shorter for execution time of programs, all programs are
executed in parallel. Lifespan of a program is decided with a reaper mechanism.
All programs are arranged in a queue, named as reaper queue, and a reproduced
program is added to the end of the reaper queue. While program execution, a pro-
gram which can correctly execute its instruction moves its position in the reaper
queue to lower, while one which cannot correctly execute its instruction moves
its position to upper. Then, when a memory space is filled, a program which
244 T. Harada and K. Takadama

is at a top of the reaper queue is deleted from the memory. Due to the reaper
mechanism, programs which cannot reproduce themselves within allocated CPU
time or include some incorrect instructions are deleted from the memory, while
creatures which can reproduce themselves propagate in the memory.
As results of such evolution, Tierra generates, for example, programs, called
parasite, which reproduce themselves by using other program’s instructions, or
ones, called hyper-parasite, which have immunity to the parasites. Note that this
evolution is not pre-programmed in Tierra but is caused by emergence [9]. As the
final stage of Tierra, programs which have shorter program size or have efficient
algorithm are generated, which require less CPU time than an initial program
to reproduce themselves [1].

4 Tierra-Based Asynchronous Genetic Programming

4.1 Overview
The previous researches focus on the feature of Tierra that can evolve programs,
i.e., digital creatures, with asynchronous execution, and have proposed a novel
GP based on Tierra mechanism, named as Tierra-based Asynchronous Genetic
Programming (TAGP) [5, 6, 11]. To apply Tierra to evolving programs with a
given task, the previous research introduces fitness commonly used in EAs to
evaluate programs, and also introduces reproduction and deletion mechanisms
depending on fitness into Tierra. This is because it is impossible to give any
purposes to programs in Tierra whose purpose is only to reproduce themselves,
and reproduction and deletions is decided depending on self-reproduction.
Figure 1 shows an image of TAGP. TAGP firstly starts from one program
which completely accomplishes the given task. Programs which consist of a lin-
ear structured instructions and some registers are stored in a limited memory
space. Each program executes a small number of instructions, which is precon-
figured, e.g., three instructions, to simulate a parallel execution. All programs
are arranged on reaper queue which controls lifespan of programs. When an
execution of one program is finished, i.e., all instructions in its program are
executed, its fitness is evaluated depending on its execution result, and the re-
production and the reaper queue control are conducted. Then if a memory is
filled with programs, programs which are arranged at the upper of the reaper
queue are removed from the memory while a vacant memory space exceeds a
certain threshold, e.g., 20% of a memory, and its space become free.

4.2 Algorithm
TAGP evolves programs through the following selection, reaper queue control,
reproduction, and deletion algorithms. The algorithm of TAGP is shown in Al-
gorithm 1. In Algorithm 1, prog.acc f it and prog.f itness respectively indicate
accumulated and evaluated fitness of evaluated fitness, and rand(0, 1) indicates
random real value between 0 to 1.
 Asynchronous Evaluation Based GP 245

memory reaper queue

C E D A B F
A B
deletion
C
registers

D F ALU
reproduction IP

program
SIZE

Fig. 1. An image of TAGP

Selection and Reaper Queue Control. When an execution of one program

is finished, its fitness is evaluated depending on its register value. Each program
accumulates fitness in every evaluations, and whether a program is selected or
not is determined based on the accumulated fitness. Here the maximum fitness
is represented as fmax , and if the accumulated fitness of a program exceeds
fmax , it is selected as a reproduction candidate, and fmax is subtracted from
its accumulated fitness (the 1st and 2nd lines in Algorithm 1). While if not,
a program is not selected. Depending on this selection condition, a program
which completely accomplishes the given task, i.e., its fitness is equal to fmax , is
invariably reproduced. High fitness programs are easy to be reproduced because
the accumulated fitness frequently exceeds fmax , while low fitness ones are hard
to satisfy this condition. Then, a position in the reaper queue of a program
that satisfies the selection condition becomes lower than the current one, i.e.,
its deletion probability decreases (the 3rd ∼ 5th lines), while one that does not
satisfies the condition becomes upper, i.e., its deletion probability increases (the
20th ∼ 22nd lines). The move distance is determined by the move rate represented
as Pdown and Pup which are calculated as the following equation based on fitness,
f fmax − f
Pdown (f ) = × Pr , Pup (f ) = × Pr , (1)
fmax fmax
where Pr is the maximum probability of Pdown and Pdown , which is preconfig-
ured. Depending on these equations, higher fitness programs are arranged on
lower position in the reaper queue, i.e., survive long, while lower ones are ar-
ranged on upper, i.e., are easily removed.
Reproduction. Programs which are selected depending on the selection con-
dition become a reproduction candidate. To reproduce better program asyn-
chronously, TAGP only compares two programs which are recently evaluated.
A better program generates a offspring with the genetic operator such as a
crossover and a mutation, and is reproduced to a vacant memory space which
is larger than a program size of the offspring (the 6th ∼ 7th lines). Additionally,
to preserve programs which can accomplish the given task, the elite preserving
strategy [7] is applied (the 8th ∼ 15th lines). Concretely, if a current program
is evaluated as fmax , it is compared with one which is recently evaluated as fmax .
246 T. Harada and K. Takadama

Algorithm 1. The algorithm of TAGP

1: if prog.acc f it ≥ fmax then
2: prog.acc f it ← prog.acc f it − fmax
3: repeat
4: down reaper queue position
5: until rand(0, 1) < Pdown (prog.f itness)
6: reproduce better program of prog and prev prog with genetic operators
7: prev prog ← prog
8: if prog.f itness = fmax then
9: if prog is better than prev elite then
10: reproduce prog without any genetic operators
11: else
12: reproduce prog with genetic operators
13: end if
14: prev elite ← prog
15: end if
16: else
prog.f itness
17: if rand(0, 1) < rand( , 1) then
fmax
18: remove prog from memory
19: end if
20: repeat
21: up reaper queue position
22: until rand(0, 1) > Pup (prog.f itness)
23: end if

Then if the current one is better, it is reproduced as an elite program with-

out the genetic operators to preserve better program, while even if not, it is
reproduced with the genetic operators. TAGP employs four genetic operators, a
crossover, a mutation, and an instruction insertion/deletion. The crossover oper-
ator combines a reproduced program with previously reproduced program. The
mutation operator changes one random instruction in a reproduced program to
other random instruction. The insertion operator inserts one random instruction
into a reproduced program, while the deletion operator removes one instruction
selected at random in a reproduced program.
Deletion. TAGP conducts two deletion. One is a reaper queue based deletion
which is conducted during the reproduction process. If a vacant memory space is
not found during the reproduction process, programs which is arranged upper in
the reaper queue are removed until a total vacant memory space becomes grater
than a certain threshold, which is preconfigured and is usually set as 20% of the
memory. This deletion remove elder and lower fitness program depending on the
reaper queue control.
While another deletion is a natural death which is applied to programs which
do not satisfied the selection condition. The natural death mechanism is em-
ployed in sugarscape [3], and removes program according to the 17th ∼ 19th line
in Algorithm 1, where rand(a, 1) indicates random real value between a(≤ 1) to
1. This deletion remove lower fitness program even if the memory is not filled.
 Asynchronous Evaluation Based GP 247

5 Experiment

To validate the effectiveness of the AEEA, and to analyze the difference of the
AEEA and the SEEA, this paper compares TAGP and simple steady-state GP
(SGP) [13] by applying two methods to a symbolic regression problem.

5.1 Example and Settings

This paper applies these methods to a symbolic regression problem. Concretely,
we use Quartic [8] which is well known and easy benchmark problem represented
as f (x) = x4 + x3 + x2 + x. As a training set, we use 16 data point from
x = {0, 1, . . . , 15}. Fitness is evaluated as the following equation

1 
N
f itness = fmax − |f (xi ) − resi | , (2)
N i=1

where fmax indicates the maximum fitness, N indicates the number of the train-
ing data, i.e., 16 in this experiment, f (xi ) indicates the function value calculated
from xi , while resi indicates the execution result of a program in respect to the
input value xi .
This paper employs a program written by actual assembly language embedded
on PIC16 micro-controller unit [10] developed by Microchip Technology Inc..
This is 12bits word assembly language, and has 33 simple instructions which
consist of add-subtract, logical, bit, and branch operations. Note that since this
language does not include a multiplication instruction, calculating multiplication
has to combine some instructions and loop structures.
Parameter settings in this experiment are shown in Table 1, 2, and 3. This
experiment compares the AEEA and the SEEA with the same number of the
evaluations. Both of TAGP and SGP employ same parameters for the crossover,
mutation, insertion, and deletion rate, while two point crossover is employed, and
the maximum fitness is set as 100. In SGP, the population size is set as 100, and
the upper execution steps are restricted to 50000 and if execution steps exceed,
its fitness becomes 0. While in TAGP, the memory size is set as 6400, 12800, and
25600 instructions, the deletion removes programs until the total vacant memory
exceeds 20% of the memory size, while Pr which is the maximum probability of
Pdown and Pup , is set as 0.9. Note that the maximum program size is configured
as 256 and the population size of SGP is configured as 100, an allocated memory
space of SGP is 256 × 100 = 25600, which is the same size with the maximum
memory size of TAGP.
The experiment conducts 30 trials in both GPs, and to evaluate the effective-
ness of the proposed method, we compare an average number of the execution
steps of the best program in the memory/population to evaluate whether an
faster program is generated.
248 T. Harada and K. Takadama

Table 1. Common parameter settings Table 2. Parameter settings of SGP

Parameter value
Parameter value Population size 100
# of evaluations 200 × 5000 Upper execution steps 50000
Crossover rate 0.8
Mutation rate 0.05 Table 3. Parameter settings of TAGP
Insertion rate 0.05
Deletion rate 0.05 Parameter value
Crossover method Two point crossover 6400
Max. program size 256 Memory size 12800
fmax 100 25600
Removing threshold 20% of memory
Pr 0.9

12000
SGP
TAGP(6400)
TAGP(12800)
TAGP(25600)
10000
average # of execution steps

8000

6000

4000

2000

0
0 1000 2000 3000 4000 5000
# of evaluation

Fig. 2. The result of the average number of the execution steps

5.2 Result
Figure 2 shows the average number of the execution steps in each GP and each
memory size. In Figure 2, the abscissa indicates the number of the evaluations,
while the ordinate indicates the average number of the shortest execution steps
of the maximum fitness program. The solid line shows the result of SGP, while
the dotted lines show the results of TAGP of the different memory sizes. Note
that all evolved programs can correctly solve the given problem. As shown in
Figure 2, in all memory sizes of TAGP, the average execution step is less than the
one of SGP. This result indicates that TAGP performs better evolution ability
than SGP. Concretely, in contrast to the evolution of SGP slows down at about
500 evaluations, TAGP keeps evolving programs and can generate the efficient
program which finishes the execution about 3000 steps. Comparing the difference
between the memory sizes of TAGP, smaller memory space get better evolution
 Asynchronous Evaluation Based GP 249

6000

5500

5000

4500
execution step

4000

3500

3000

2500

2000
SGP TAGP(6400) TAGP(12800) TAGP(25600)

Fig. 3. A boxplot of the execution steps for each GP method

ability. From these results, it is revealed that TAGP has better evolution ability
than SGP on the symbolic regression problem, and additionally, the smaller
memory size accelerates the program evolution.
Figure 3 shows a boxplot of the execution steps finally given by the best
program in the memory/population after 200×5000 evaluations. In Figure 3, the
abscissa indicates the difference of the GP methods, while the ordinate indicates
the execution steps finally given by the best program in the memory/population.
As shown in Figure 3, it is indicated that the execution step of evolved programs
with TAGP is shorter than 3500, while the one with SGP is weighted from
3200 to 4200. Focusing on the difference between the memory size of TAGP, the
variability of the execution steps is small in the case that the memory size is 6400,
while in the case that the memory size is 12800 and 25600, shorter execution step
programs which is about 2300∼2400 are generated that are not generated with
small memory size TAGP or SGP. From these results, it is revealed that TAGP
can generate shorter execution step programs than SGP, and the small memory
size enables stable program evolution, while the large memory size enables to
generate shorter step programs than the small memory size or SGP.

6 Discussion

The average program size of the best program in the memory/population is

shown in Figure 4. In Figure 4, the abscissa indicates the number of the eval-
uation, while the ordinate indicates the average program size of the maximum
fitness and the shortest execution steps program. The solid line shows the result
of SGP, while the dotted lines show the results of TAGP of the different mem-
ory sizes. As shown in Figure 4, the average program size increases at the early
evolution period. This is because the program evolution of this problem mainly
250 T. Harada and K. Takadama

300
SGP
TAGP(6400)
TAGP(12800)
TAGP(25600)
250

200
average program size

150

100

50

0
0 1000 2000 3000 4000 5000
# of evaluation

Fig. 4. The result of the average program size

expand loop structures. Since a loop expansion can reduce a number of judge
of a termination condition, it decreases the execution steps. Comparing TAGP
with SGP, although TAGP decreases the program size after size increasing, SGP
keeps large program size. From the viewpoint of the program size, since the max-
imum program size is limited to 256, programs which is larger than the limit
cannot be generated. However, although it is required to expand loops to evolve
program in this experiment, a large program cannot expand its loop because of
the size limitation. Therefore, since it is hard for a large program to be evolved
by expanding the loops unless become small by removing inefficient instructions,
the program evolution of SGP which keeps large program size slows down. In
contrast to this, since TAGP can decreases the program size and leaves space
for the evolution, TAGP can keep evolving the program. The reason why TAGP
can decrease the program size is that TAGP restricts the large program size be-
cause of controlling the population based on the memory size, where the smaller
program easily survives.
Finally, to clarify the difference of the diversity between TAGP and SGP, the
standard deviation of the execution steps in the memory/populaiton is shown in
Figure 5. In Figure5, the abscissas indicate the number of the evaluation, while
the ordinates indicate the average of the standard deviation of the execution
steps in the memory/population. The solid line shows the result of SGP, while the
dotted lines show the results of TAGP of the different memory sizes. As shown
in Figure 5, the standard deviation of the execution steps in TAGP is larger than
the one in SGP, which indicates that the diversity of the programs in TAGP is
larger than the one in SGP. This is because since TAGP selects programs based
on fitness and execution completion, faster programs have selection probability
even if they are not the best, in contrast to SGP selects programs with absolute
comparison based on fitness and actual execution steps where it is very hard
 Asynchronous Evaluation Based GP 251

3000
SGP
TAGP(6400)
TAGP(12800)
TAGP(25600)
2500
average of standard deviation of execution steps

2000

1500

1000

500

0
0 1000 2000 3000 4000 5000
# of evaluation

Fig. 5. The average of the standard deviation of the execution steps

for slower programs to be selected. This feature is the common advantage of

the AEEA approaches to be able to preserve the diversity of population because
of the asynchronous evaluation. It is revealed that the asynchronous evaluation
also contributes better evolution ability in the GP domain.

7 Conclusion

This paper focused on the asynchronous evaluation on the GP domain, ana-

lyzed the difference between the synchronous and the asynchronous evaluation
based GPs. Concretely, this paper compares TAGP as the asynchronous evalu-
ation based GP we proposed with simple steady-state GP as the synchronous
evaluation based GP. The intensive experiment is conducted to investigate the
effectiveness of the asynchronous evaluation on the GP domain by applying
these two methods to the symbolic regression problem. The experiment has re-
vealed that TAGP has better evolution ability than SGP, and the small memory
size accelerates the program evolution, while the large memory size generates
shorter execution step programs than the small memory or SGP. The reason
of this improvement is that TAGP can naturally restrict to generate the larger
size program because of the memory size based population control, while TAGP
can also preserve the diversity of the population because of the asynchronous
evaluation.
The following issues should be pursued in the near future: (1) experiments on
other benchmark problems such as boolean and classification and a comparison
with other GP methods, and (2) an improvement of evolution ability of TAGP.

Acknowledgments. This work was supported by JSP KAKENHI Grant Num-

ber 249376.
252 T. Harada and K. Takadama

References
1. ATR Evolutionary Systems Department: Artificial Life and Evolutional System.
Tokyo Denki University Press (1998)
2. Durillo, J.J., Zhang, Q., Nebro, A.J., Alba, E.: Distribution of Computational
Effort in Parallel MOEA/D. In: Coello, C.A.C. (ed.) LION 2011. LNCS, vol. 6683,
pp. 488–502. Springer, Heidelberg (2011),
http://dx.doi.org/10.1007/978-3-642-25566-3_38
3. Epstein, J.M., Axtell, R.L.: Growing Artificial Societies: Social Science from
the Bottom Up (Complex Adaptive Systems), 1st printing edn. The MIT Press
(November 1996), http://www.amazon.com/exec/obidos/
redirect?tag=citeulike07-20&path=ASIN/0262550253
4. Goldberg, D.E.: Genetic Algorithms in Search, Optimization and Machine Learn-
ing, 1st edn. Addison-Wesley Longman Publishing Co., Inc., Boston (1989)
5. Harada, T., Otani, M., Matsushima, H., Hattori, K., Sato, H., Takadama, K.: Ro-
bustness to Bit Inversion in Registers and Acceleration of Program Evolution in
On-Board Computer. Journal of Advanced Computational Intelligence and Interl-
ligent Informatics (JACIII) 15(8), 1175–1185 (2011)
6. Harada, T., Otani, M., Matsushima, H., Hattori, K., Takadama, K.: Evolving Com-
plex Programs in Tierra-based On-Board Computer on UNITEC-1. In: 2010 61st
World Congress on International Astronautical Congress (IAC) (2010)
7. Jong, D., Alan, K.: An Analysis of the Behavior of a Class of Genetic Adaptive
Systems. Ph.D. thesis, Department of Computer and Communications Sciences,
University of Michigan (1975)
8. Koza, J.: Genetic Programming On the Programming of Computers by Means of
Natural Selection. MIT Press (1992)
9. Langton, C.G.: Artificial Life. Addison-Wesley (1989)
10. Microchip Technology Inc.: PIC10F200/202/204/206 Data Sheet 6-Pin, 8-bit Flash
Microcontrollers. Microchip Technology Inc. (2007),
http://ww1.microchip.com/downloads/en/DeviceDoc/41239D.pdf
11. Nonami, K., Takadama, K.: Tierra-based Space System for Robustness of Bit In-
version and Program Evolution. In: SICE, 2007 Annual Conference, pp. 1155–1160
(2007)
12. Ray, T.S.: An approach to the synthesis of life. Artificial Life II XI, 371–408 (1991)
13. Reynolds, C.W.: An evolved, vision-based behavioral model of coordinated group
motion. In: Proc. 2nd International Conf. on Simulation of Adaptive Behavior, pp.
384–392. MIT Press (1993)
14. Storn, R., Price, K.: Differential Evolution - A Simple and Efficient Heuristic for
Global Optimization over Continuous Spaces. J. of Global Optimization 11(4),
341–359 (1997), http://dx.doi.org/10.1023/A:1008202821328
15. Tasoulis, D., Pavlidis, N., Plagianakos, V., Vrahatis, M.: Parallel differential evolu-
tion. In: Congress on Evolutionary Computation, CEC 2004, vol. 2, pp. 2023–2029
(June 2004)
16. Zhang, Q., Li, H.: MOEA/D: A Multiobjective Evolutionary Algorithm Based on
Decomposition. IEEE Trans. Evolutionary Computation 11(6), 712–731 (2007)