diff options
Diffstat (limited to 'res/README')
| -rw-r--r-- | res/README | 214 |
1 files changed, 214 insertions, 0 deletions
diff --git a/res/README b/res/README new file mode 100644 index 0000000..b73e257 --- /dev/null +++ b/res/README @@ -0,0 +1,214 @@ +- 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). + + +15/2 + +The Population class will be refactored to contain two collections of chromosomes, one for parents and one for offpsring. This allows +for (1+λ) and (1,λ) EAs, for example. It no longer makes sense for Population to implement Iterable, so the tests will be changed to reflect +the specification change. Population can still return an addressed chromosome in general, which it does by returning parents followed by offspring. + +The chromosome copyConnections method has been made public to facilitate the EA implementation. + + +16/2 + +Methods were added to Chromosome and Connection to allow the chromosome to be printed to the console. This way its behaviour can be verified to make +sure the fitness evaluations are working correctly and any perfect solution found really is producing perfect outputs. + +A test case has been calculated by hand from the printed chromosome, and indeed the system appears to be working. + +However, if the implemented run() in Function subclasses is set to print the operation it has carried out, the first function execution of each output +prints twice -> because it needs to check what it is to cast it. Very inefficient... +Instead, we'll attempt to cast it without checking, and a ClassCastException will be raised if a problem happens, telling the user they did something wrong. +This can be caught by the GUI to display an error message, if necessary. + +Added a new parameter, debug. When set to true, the system prints a lot of information to the console for debugging purposes. + +Added some more functions. + +8/3 + +Adding GUI package, refactoring CGP class to interact appropriately with GUI. + +15/3 + +Currently refactoring Parameters. It is now a part of CGP.class as stated in the phase report. The rest of the program will now be refactored to accommodate +these changes. Inversion of control will be employed to avoid static accesses to CGP, and the tests will be modified accordingly. +This will allow multiple instances of CGP to co-exist. + +18/3 + +The current state of parameters is not yet perfect. One more refactoring will be carried out to speed up GUI updates. +Modules will be required to return a hashmap of parameters so the GUI can be re-built easily whenever modules change. +Modules should instantiate their parameters in their constructor and use direct referencing internally for extra speed. +The hashmap may be pre-built to save time when getParameters() is called, though this is not critical. + +19/3 + +Refactoring is complete, population tests have been refactored as well. It is worth noting that the new resources +framework leads to a lot of confusing casting. Utility methods will be written to hide away the casting in the CGP +class and simplify the programmer's life. +Registering parameters is no longer necessary. The CGP class will query modules for their parameters when necessary. + + +21/3 + +FunctionSet has been rewritten to allow only certain functions to be deactivated, the GUI will now be integrated. + + +25/3 + +http://andrewtill.blogspot.ch/2012/12/dragging-to-resize-javafx-region.html + +Looking into drag-to-resize for the console and the menu. All sorted. + +Settings and console can be resized but not beyond a minimum value, and the +grid node grows to fill the void. + + +26/3 + +Sorted out the console, resizing is mint, settings are nearing completion and the node grid has been refactored multiple times. + + +28/3 + +Refactoring parameters to overhaul the mechanism that allows modules to manage parameters.
\ No newline at end of file |