diff options
| -rw-r--r-- | .project | 2 | ||||
| -rw-r--r-- | res/README | 214 |
2 files changed, 1 insertions, 215 deletions
@@ -1,6 +1,6 @@ <?xml version="1.0" encoding="UTF-8"?> <projectDescription> - <name>CGPDevelopment</name> + <name>JCGP</name> <comment></comment> <projects> </projects> diff --git a/res/README b/res/README deleted file mode 100644 index 01d985a..0000000 --- a/res/README +++ /dev/null @@ -1,214 +0,0 @@ -- 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 Mutable. 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 |