- Development Branch - 29/1 Started formal development based on data_struct spike. The first goal is to produce the data structure that represents a chromosome. This structure will rely on a range of other classes, which will be developed and tested as well. Chromosome tests: - a data structure called Chromosome exists - the chromosome instance can return the right outputs based on given inputs ChromosomeElement tests: - Node is capable of processing its connections using its function and returning the result - Input returns the value it is set to - Outputs returns a single value from its source Node 30/1 Added class representations of functions and mutators, as well as the program itself (CGP). Modified the way the chromosome stores its data to allow for more flexible mutations. 31/1 Parity will be considered constant, at 2, for now. Added static nested classes for system-wide resources such as a random number generator, the function set and the parameter set. These can be accessed from anywhere within the program, but not modified by any class but CGP. Utilities class has lots of handy methods for getting random elements with fair probability. Modularized design: Modules for fitness function, mutation operator, evolutionary algorithm and population. FF, EA and mutation modules act as callbacks; the user may specify how the module does its job, but must comply with the interface. Population is slightly more complex: the user may define a custom chromosome and use it to generate a population, so long as it extends Chromosome. In conjunction with modularized FF, EA and mutation, this makes for a very flexible and versatile system. The Population class itself is immutable, since the system relies heavily on it. Finally, it is Iterable to for access to the chromosomes within. Arity may vary across functions, but all nodes contain enough connections to cope with the largest arity. FunctionSet presents a bit of a problem in case the user retains references to the Functions passed into it. 3/2 Solved the FunctionSet problem; since Function does not specify a way to modify the function once it is instantiated, concurrent accesses should not be a problem. Should the user extend Function and implement a way to modify it at runtime, the CGP program won't really use it; if the user modifies the CGP program to use it, then the user must be ready to deal with the consequences. A fitness evaluation testbench of sorts will be implemented next. This testbench will take a set of "stimuli" (inputs), use them to compute outputs with each chromosome, and compare those with the expected outputs, thus assigning fitness. This will be achieved for now using a TestCase object which contains a set of inputs and outputs. The evaluator simply sets the chromosome inputs and compares outputs for all TestCase objects given, and computes a fitness function accordingly. 4/2 TestCase has been implemented with a fair degree of defensiveness. A TruthTable class contains the test cases and provides a way to evaluate fitness. TruthTable is a system-wide resource, which may or may not be used by FitnessFunction to assign fitness values to the population; that is up to the user. A standard fitness function which uses TruthTable is defined in TruthTableEvaluator. StandardMutator has been implemented, though it looks like it may need refactoring in the future. StandardEA presents a problem: mutating the highest fitness chromosome to generate a new population requires the chromosome to be copied, which is not straightforward in OOP. This could be addressed by creating a shallow copy and instantiating new Nodes during the mutation process. This is actually an implementation of a lazy copy which takes advantage of common Nodes to save memory. Additionally, this will require the mutation to actually occur within the chromosome and simply be triggered from the Mutator. This reduces the number of Utilities functions, which is not necessarily a problem. 7/2 The resource classes have been refactored so that tests can be implemented more easily. Parameters, Utilities and TruthTable are now top-level classes and work independently from CGP, allowing them to be initialised for testing purposes. Some chromosome tests have been written and more tests will be written in the next few days. 11/2 Methods to get random connections and mutable elements have been moved into Chromosome, as well as refactored to require less random number generations. Chromosome and its associated members (Node, Output, Input) have been refactored to allow copying. A copy constructor has been written which initialises a new chromosome as an exact copy of a given chromosome. Cloning has been tested and is working. Active node detection will be implemented via a getActiveNodes() method in Chromosome. The chromosome is notified whenever one of its nodes or outputs is mutated, and re-computes the list of active elements when it is required. It does so by recursively acquiring node connections and copying them to a separate list, unless they are already on the list. All chromosome tests have been implemented. 12/2 Node tests done. Added exception support for Function in case not enough argument connections are given. Chromosome tests refactored to include the special case where columns = 1. Input and output tests written. Population tests under way. 13/2 Writing the test for the population copy constructor will require the production of a method which compares two chromosomes. Therefore, two new methods will be written for Chromosome: compareTo and compareActiveTo. Compare returns true if the two chromosomes are exclusively equivalent, and compareActive returns true if the active nodes within the two chromosomes are exclusively equivalent. Compare methods done, including their "dependency": copyOf method in MutableElement. This method is akin to equals(), with the exception that it returns false when the compared objects are pointers to a common instance. Minor update: Node now passes only the necessary number of arguments into its function; this allows the node to compute its active connections as it knows which connections the function will use (based on arity). 14/2 Support for generic data types implemented. Tests have been refactored to deal with the new data system. The system uses Object as its data type, allowing absolutely any class to be used (and also primitive types).