Evolvable objects

One of the most famous Evolutionary Computation books is called Genetic Algorithms + data structures = Evolution Programs [2]. The approach implied by this title predates EO, in the sense that it proposes to free EC from representation, using bit strings or floating point vectors as the researcher sees fit, but at the same time, it shows the main paradigm of procedural programming applied to EC: algorithms are applied to data structures, which are distinct and separate, and all together form evolution programs.

However, procedural programming is not the only language paradigm today: many languages, and most of the mainstream languages, are object oriented. Object oriented (evolutionary) computation could be expressed this way: Algorithms along with Data structures = evolution objects. In object-oriented computation, algorithms and the data structures which they are applied to are encapsulated within an object, and the interaction with it is regulated through an interface, which is designed by the programmer. An object knows its own inner workings, but anybody using that object (the client of that object) can only use it through its interface. What features should, then, provide the interface of an object in order to make it evolvable?. At least, it should be replicable, mutable, combinable and comparable. These properties will be examined in turn:

• Replicability It should be possible to obtain copies of an EO, be it by itself or through the use of other objects (replicators); it should also be possible to create EOs from scratch, using EO factories.
• Mutability An EO should be able to mutate, or change, in a way that it increases the diversity of a pool of EOs (obviously called population). This only means that the EO, or whatever object is devoted to change it (a mutator), can change in one or several ways, but the inner workings of the mutation need not be known from outside, neither a particular representation will be needed in order to mutate. The client can only be guaranteed that the object will change in a particular way.
• Combinability In some cases, it is possible to combine two or more EOs to create a new one (in similar way to GA's crossover). This is not always possible, but when it is, the operation decreases diversity, in the sense that it makes the EOs in the population more similar to each other. As it happens with mutation, the exact inner workings of combination (or crossover) need not be known by the client.
• Comparability In order to decide which objects are better than others at a particular task, it should be possible to compare objects and select one as the best. This does not mean that EOs should have an scalar fitness (so that fitness-proportional selection could be carried out), or even that fitness should be explicit; in order to select the best or the fitter, it is just necessary to be able to separate them from the worst. Then, an object (a selector) can be used to eliminate the worst, and keep the best, applying mutators, maters (objects that combine other objects), or EO factories to substitute them, if needed.

What are, then, the main differences among EO and all the other EC paradigms?, and, the million-dollar question, is it really new?. We could enumerate some differences:

• EO is paradigm-independent, which means that it is neither a genetic algorithm, nor an evolution program, nor a genetic program, nor even a simulated annealing algorithm, but can be all of them, and, in fact, all those EC paradigms can be casted within the EO paradigm. For instance, in a simple GA, the mutator would be the bitflip mutation operator; the mater, whatever (subroutine, procedure) applies the crossover operator, scalar fitness would allow comparison of all EOs, and, using it, roulette wheel selection would allow the best to mate and the worst to vanish. In simulated annealing, there would be no mater, but the mutator would be the operator that changes single traits in the solution, the cost function would make comparison between solutions and stochastical selection of the best possible. Varying population sizes, or GAs with ages, fall also within EO's framework.
• EO is representation-independent. EO does not care at all about how solutions to a problem can be represented, just about the fact that they can be changed, and, if applicable, combined. In fact, EO does not even need to represent solutions in a way different than coding them in an object-oriented language: a solution to a problem can be an object, and if this object can be mutated and compared (and maybe combined with other objects) it is enough for evolving it.
• EO is language-independent, which means that it does not need to represent solutions in a particular language, like Genetic Programming does. Solutions can be written in any object-oriented language, like some versions of LISP itself, Modula-2, Smalltalk, Objective-C, Java and C++, and they might be evolved within the framework of the same language, without the need of a virtual machine to run them. EOs can even be programmed and used from many different languages at the same time, by using language-independent object models like Microsoft's COM, Object Management Group Common Object Request Broker Arquitecture (CORBA) or the World Wide Web Document Object Model. This would permit the integration of evolutionary computation into current operating systems and user interfaces. So far, our team is working on the integration of evolutionary computation into the Windows family by including EO within an ActiveX control.
• EO is object oriented from the ground up: not only the object or class of objects that is going to be evolved is programmed in this way, but also the rest of the elements intervening in the evolution process: operators, selectors and the algorithms themselves.

EO emphasizes modularity in programming an evolutionary or evolving application. Since operators and the rest of the entities are objects, it is easy to combine different operators and objects coming from different sources to build an application. In practice, it does not matter what the object to be evolved has inside, but what it looks like, that is, the interface it presents to its clients. If it can be compared, there are genetic operators that can be applied to it, be them unary or binary, it does not matter how those operations are carried out inside, and it can be evolved using the EO framework. This focus on interfaces would also make possible to write an object in C++, and evolve it using Java (which are two object-oriented languages), or the other way round. In practice, the EO engine could be written in any language, and it could be used on objects written in any other language. So far, the only EO engine is written in C++, and through an ActiveX control that uses EO, it can be used from any language or application that can work as ActiveX container. ActiveX controls are part of the COM framework [9], which allows objects in Microsoft Windows9x/NT use all the other objects in the operating system and applications.

To cast evolutionary computation in an object-oriented framework like EO allows to integrate it into current object frameworks, such as the Object Management Group's CORBA [10] (Common Object Request Broker architecture) or Microsoft's COM (Common Object Model)[9].