diff options
Diffstat (limited to 'res')
| -rw-r--r-- | res/README | 214 | ||||
| -rw-r--r-- | res/cgp0.chr | 1 | ||||
| -rw-r--r-- | res/epar3.plu | 5 | ||||
| -rw-r--r-- | res/mult2.plu | 5 | ||||
| -rw-r--r-- | res/parameters.par | 32 | ||||
| -rw-r--r-- | res/quintic-polynomial.dat | 26 | ||||
| -rw-r--r-- | res/test | 1 | ||||
| -rw-r--r-- | res/test.chr | 1 | ||||
| -rw-r--r-- | res/test~ | 1 |
9 files changed, 286 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 diff --git a/res/cgp0.chr b/res/cgp0.chr new file mode 100644 index 0000000..3157c03 --- /dev/null +++ b/res/cgp0.chr @@ -0,0 +1 @@ + 1 2 7 1 2 6 2 2 7 3 2 7 2 0 7 3 0 7 0 1 7 7 1 10 6 0 7 10 11 7 2 11 7 0 11 6 13 0 7 13 12 10 14 1 7 16
\ No newline at end of file diff --git a/res/epar3.plu b/res/epar3.plu new file mode 100644 index 0000000..b554b66 --- /dev/null +++ b/res/epar3.plu @@ -0,0 +1,5 @@ +.i 3
+.o 1
+.p 1
+240 204 170 105
+.e
\ No newline at end of file diff --git a/res/mult2.plu b/res/mult2.plu new file mode 100644 index 0000000..e629d28 --- /dev/null +++ b/res/mult2.plu @@ -0,0 +1,5 @@ +.i 4
+.o 4
+.p 1
+65280 61680 52428 43690 32768 19456 27328 41120
+.e
\ No newline at end of file diff --git a/res/parameters.par b/res/parameters.par new file mode 100644 index 0000000..bf38c11 --- /dev/null +++ b/res/parameters.par @@ -0,0 +1,32 @@ +5 population_size +1.0 per_cent_mutate +10000 num_generations +10 num_runs_total +1 num_rows +100 num_cols +100 levels_back +1 progress_report +1000 report_interval +173156789 global_seed +0 run_from_chrom +0 shrink_phenotype +0 1 modulus-0 +0 1 sqrt-1 +0 1 reciprocal-2 +0 1 sin-3 +0 1 cos-4 +0 1 tan-5 +0 1 exp-6 +0 1 sinh-7 +0 1 cosh-8 +0 1 tanh-9 +0 1 nat-log-10 +0 1 logbase10-11 +0 2 sin(a+b)-12 +0 2 cos(a+b)-13 +0 2 hypoteneuse-14 +0 2 power-15 +1 2 addition-16 +1 2 subtraction-17 +1 2 multiplication-18 +1 2 division-19
\ No newline at end of file diff --git a/res/quintic-polynomial.dat b/res/quintic-polynomial.dat new file mode 100644 index 0000000..347b95a --- /dev/null +++ b/res/quintic-polynomial.dat @@ -0,0 +1,26 @@ +.i 1
+.o 1
+.t 21
+-1.0 0.0
+-0.9 -0.03249
+-0.8 -0.10368
+-0.7 -0.18207
+-0.6 -0.24576
+-0.5 -0.28125
+-0.4 -0.28224
+-0.3 -0.24843
+-0.2 -0.18432
+-0.1 -0.09801
+0.0 0.0
+0.1 0.09801
+0.2 0.18432
+0.3 0.24843
+0.4 0.28224
+0.5 0.28125
+0.6 0.24576
+0.7 0.18207
+0.8 0.10368
+0.9 0.03249
+1.0 0.0
+.e
+
diff --git a/res/test b/res/test new file mode 100644 index 0000000..2957b44 --- /dev/null +++ b/res/test @@ -0,0 +1 @@ + 2 2 13 0 1 12 0 1 14 1 2 10 2 0 9 1 6 13 0 1 14 10 10 14 12 0 17 14 1 10 9 9 17 12 12 6 15 2 13 18 18 16 0 2 15 12 12 18 16 2 12 1 0 10 1 1 18 1 28 18 15 15 9 20 20 6 0 2 10 1 30 19 35 35 4 0 1 2
\ No newline at end of file diff --git a/res/test.chr b/res/test.chr new file mode 100644 index 0000000..34664df --- /dev/null +++ b/res/test.chr @@ -0,0 +1 @@ + 0 0 7 0 0 6 0 0 15 0 0 6 0 0 18 2 0 6 2 0 8 1 3 14 5 0 13 2 4 11 4 2 14 4 2 0 3 6 2 2 5 1 3 1 6 6 5 3 5 5 9 3 3 13 4 2 19 3 4 18 5 5 11 7 6 5 4 7 12 0 5 4 3 5 7 3
\ No newline at end of file diff --git a/res/test~ b/res/test~ new file mode 100644 index 0000000..2957b44 --- /dev/null +++ b/res/test~ @@ -0,0 +1 @@ + 2 2 13 0 1 12 0 1 14 1 2 10 2 0 9 1 6 13 0 1 14 10 10 14 12 0 17 14 1 10 9 9 17 12 12 6 15 2 13 18 18 16 0 2 15 12 12 18 16 2 12 1 0 10 1 1 18 1 28 18 15 15 9 20 20 6 0 2 10 1 30 19 35 35 4 0 1 2
\ No newline at end of file |