Perhaps the most interesting result to come out of this research has been the analysis of the role of contingency in determining the course of evolution. In Section 6.1 we discovered that in a set of 19 runs of Cosmos which differed only in the number used to seed the random number generator, each one performed significantly differently, in a number of measures, from at least one third of the other runs. Using these results, it was decided that each Cosmos experiment in future should be run at least nine times in order to be confident of seeing a variety of results.
Despite the significant quantitative differences that arise, by chance, between many of the runs, we have seen that the system's behaviour can generally be categorised into one of two classes proposed by Bedau and colleagues [Bedau et al. 98]. This finding is reminiscent of the evolutionary dictum of ``laws in the background and contingency in the details'' discussed in Chapter 2 (Section 2.3.5), although in the present case even the background laws would appear to be rather dependent upon the details of the system's design.
During Class 2 dynamics, the population of programs is able to evolve fairly successfully. The chief methods by which adaptive improvements are made are by the accumulation of et_collect instructions within the programs (enabling them to collect more energy from the environment), and by the removal of redundant instructions. Note, however, that there is a limit to the extent that each of these methods can be applied; in Section 6.3.1 we saw that as the number of et_collect instructions in a program's copy loop was increased, the system moved towards Class 1 dynamics, where evolution effectively ceases; also, there is obviously a limit to the number of redundant instructions that can be removed from the programs. Once these limits have been reached, another kind of adaptive innovation would have to be discovered to allow the system to continue evolving, but we have so far seen little evidence for other innovations of this nature.
The other category of behaviour that was often observed was Class 1 dynamics. Analysis of runs which had switched to this state revealed that it is degenerative from an evolutionary point of view, because adaptive innovations are no longer able to spread through the population. The transition from Class 2 to Class 1 dynamics is usually brought about by the appearance of programs much longer than the ancestor (typically in the range of 600-1200 bits). Under the standard parameter settings whereby CPU-time is allocated to programs according to their length, longer programs such as these are able to collect more energy from the environment per time slice, giving them an advantage over their shorter ancestors. The onset of Class 1 dynamics can be avoided by using a length-neutral CPU-time allocation scheme (Section 6.4). The evolutionary activity of the system in the Class 1 state can also be improved by using a private energy collection scheme (Section 6.5.2).
Another interesting result was the speciation6.10 of programs of different lengths, observed in the experiments in which a large gradient existed in the distribution of environmental energy across the grid (Section 6.5.3). This result suggests that a heterogeneous environment is an important factor in the emergence of speciation, and also demonstrates that it is not necessary to have a physical boundary for the population to differentiate into a number of species. In biological terms, the origin of species which live in the same place is called sympatric speciation. A number of processes have been proposed to explain this phenomenon, but the mechanisms involved are usually somewhat more complicated than the simple gradient in resource availability involved in these Cosmos runs [Maynard Smith 89]. Although the experiments reported here cannot really tell us much about this issue,6.11 they do at least demonstrate the potential of spatially explicit, individual-based models to investigate such questions.
The experiments with sexually reproducing ancestors reported in Section 6.7 demonstrated that this capacity is easily lost. In all of the runs, the sexual ancestors were rapidly displaced by asexual programs. Further analysis revealed that this may have been partially due to the ease at which the sexual ancestor could be mutated into a functional asexual program. However, the results still suggest that it might be hard to devise an environment in which sexual programs have a selective advantage.
Finally, another phenomenon which arose on a number of occasions was the so-called `cancer' mutation (Sections 6.3.2, 6.5.2, 6.5.3 and 6.7). This mutation resulted in an extra instruction being tacked onto the end of a program's offspring at each reproduction. Over the generations the size of this tumour therefore grew larger and larger, resulting eventually in the death of the programs and the extinction of the population (unless the tumour happened to be composed of energy collection instructions). Although this result bears little relation to cancer in biological organisms, it does at least demonstrate how mutations which are harmful to the population in the long-run can initially be selected for and thereby invade the population.
Two things which we have not observed in evolutionary runs with Cosmos are the appearance of parasites or similar symbiotic phenomena, and the appearance of multicellular (parallel) programs.
The fact that parasites did not evolve in Cosmos, unlike in Tierra, was anticipated. Their emergence in Tierra depends upon some fairly specific aspects of the system's design and of the ancestor program used, as discussed in Chapter 3 (Sections 3.2.1 and 3.3.1). As the design of Cosmos differed from Tierra in these respects, it is much harder for evolution to `discover' parasites in Cosmos. This highlights the importance that seemingly innocuous design features might have in determining the behaviour of artificial life platforms such as these, and suggests that we should take great care when claiming anything about the generality of results obtained from any particular one.
Recall from Chapter 4 that one of the original reasons for building Cosmos was to create a platform in which the emergence of multicellular programs might occur fairly easily. However, the experiments reported in this chapter have been concerned with exploring rather more basic aspects of the system's design, and we have not yet had the opportunity to look into the issue of multicellularity in a systematic way. As a passing note, developmental biologist Lewis Wolpert has suggested that multicellular organisms might originally have emerged in conditions where food was sparsely distributed in the environment.6.12 When no food was available, a multicellular organism would be able to begin eating its own cells to survive until environmental food was available again. The experiments with environmental energy gradients and with random energy distribution reported in this chapter could be seen as a recreation of such a scenario, but no multicellularity was observed in them. However, a much more thorough investigation into this topic is required before anything can be said on the matter.
Although this chapter has been rather long, we have really only just scratched the surface of exploring the parameter space. We cannot claim to have thoroughly investigated the parameter space for those parameters discussed in this chapter, and indeed we have not even begun to investigate the effect of varying the parameters listed in Section B.1. Many of these concern the mechanisms for dealing with environmentally-conveyed messages, and various factors involved with multicellular (parallel) programs. The sexual ancestor reported in Section 6.7 did use environmentally-conveyed messages, but this ability was rapidly lost during the course of evolution.
All of the experiments except those reported in Section 6.7 used the same ancestor program, 348AAAA. There is an infinite variety of other ancestors which could have been used, some of which would have undoubtedly led to very different results. For example, one of the theories which has been put forward to explain the sudden origin and rapid explosion in diversity of multicellular biological organisms during the late Precambrian sees the evolution of heterotrophs (i.e. organisms which eat other organisms in order to obtain the complex organic compounds they require for metabolism) as the prime cause [Stanley 73]. Such a scenario could be recreated in Cosmos by introducing heterotrophic organisms (modelled as programs which kill other programs to steal their energy reserves),6.13 in an effort to bring about a similar explosion in diversity. Indeed, initial experiments in this direction have been attempted, but it has so far proved impossible to engineer a viable community that includes heterotrophic programs.
A final feature of the model which has received little attention is the mapping between a program's genome (represented as a string of binary digits), and the instructions in the language provided. At present, there are 62 instructions in the Cosmos instruction set, and these are encoded using six bits (giving a total of 64 different possibilities). All of the runs reported in this thesis have used the same mapping, in which each of the 62 instructions is represented once, except the move instruction which appears three times (see Section B.4). There is therefore virtually no redundancy in the encoding, in contrast to the biological genetic code which encodes 20 amino acids with 64 possible codons. An alternative design has been developed, which uses a reduced instruction set. This consists of just 21 primary units which can be encoded on the genome. The full functionality of the existing system is maintained by allowing the primary units to form compound instructions. This is somewhat analogous to the way in which biological genomes encode just 20 amino acids, which, when decoded, are then assembled into a vast array of useful proteins. It may turn out that such redundancy would have a considerable effect upon the evolvability of the system. For example, important or frequently-used instructions in the language could be represented by multiple codons, thereby biassing the system to use these rather than some of the more obscure instructions. However, this design has so far not been implemented.