Moved files around to different folders, and commented some more packages. Aiming to have the entire backend fully commented by the end of today

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