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

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