Removed old README, renamed project to JCGP

2 files changed, 1 insertions, 215 deletions

diff --git a/.project b/.project
index 47b759e..5e02149 100644
--- a/.project
+++ b/.project
@@ -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