Crossover/Mutation:
- Split into individual and population subclasses.
- Added sequential population crossover selection.
- Renamed and reimplemented mutation methods.
EasyGA:
- Improved make_obj methods for the chromosomes and populations to take arguments.
Initialization:
- Improved to shorter code.
- Fixed repeated error messages
Chromosome:
- Changed get/set_genes to get/set_gene_list.
1. Deleted duplicate functions in EasyGA
2. Added new index-dependent fitness example
3. GA now auto-sorts by best fitness immediately after the fitness is calculated across the board
4. Removed 'selected' status flag from the Chromosome flag
5. Added mating_pool attribute to the population
6. Changed other code to be in line with 4 and 5
7. Optimized tournament selection method
Instead of a nested approach, selection/crossover/mutation are all called separately and directly by the GA. selection_impl was also separated into parent_selection_impl and survivor_selection_impl, as both are needed separately.
The current test implementation includes random mutation, single point crossover, and tournament selection. The implementation, in short, is a nested approach. The selection method is the only thing actually called by the GA. Both crossover and mutation occur within the selection method. As long as these three systems all follow a standard input/output system, any implementation we build, as well as any user implementations, will work perfectly. The selection function must take GA as a parameter and output a new population. Crossover takes in GA and outputs a population. Mutation takes a chromosome set and outputs a new chromosome set.
Many of the changes in this commit are regarding this test implementation. I have also changed many of the file names from "x_examples" to "x_types" and updated the class names to follow capitalziation standards. I did this because I feel personally like the built-in mutation, crossover, and selection implementations are less "examples" and more just already built implementations to make the code required from the user smaller.
1) The initialization now accepts "general" inputs that should apply to each gene. For example, rather than a gene input of [1,100] being interpreted to mean gene 1 hsould be 1 and gene 2 should be 100, it will apply a range of [1,100] to each gene.
2) The initialization now accepts "general" gene_input_types. For example, if the user had a set of index-dependent number values, they could just say ga.gene_input_type = "domain" and the package will propagate that across all genes in the chromosome. The user still has the option of defining the entire array or just defining a specific element if they so choose. For later commits, the general gene_input_type will have to be checked for validity; for example, a string can never be a range.
3) Fixed an issue in the ordering of the initialization function call.
4) Added comments surrounding the signfiicant changes to the initialization.
5) Added example tests to the testing file.
Random gene initialization now supports float ranges (assumed by default if gene input includes float). Backend was also optimized and cleaned up greatly.
This is a test implementation of a potential new initialization method. A testing file - new_initialization_method_testing.py - is included to allow for quick testing.
In summary here is are the major points:
1) Two new attributes of GA were created - gene_input and gene_input_type. gene_input holds the user's custom range(s)/domain(s) after it gets passed to the initialize() function. gene_input_type holds an array with the same length as the chromosomes that holds the input type of the user's gene_input on a gene-by-gene basis. It does this in the same exact way that index-dependent gene ranges/domains are handled. By making the gene_input_type array the same size as the chromosome, the elements can be paired very easily. The acceptable values for this are either "range" or "domain". With a range, any value between the two can be generated; with domain, only the two elements included can be selected from randomly.
2) As mentioned in change 1, the user now has to pass their range(s)/domain(s) to the initialize() function.
3) The package is capable of implicitly determining if a certain input from the user is a range or domain. Strings can only ever be a domain – if given an element that only includes integers, the program assumes range.
4) If the user wishes to use numbers only as a domain, they can specify this by directly interacting with the ga.gene_input_type (or through a setter function).
5) the initialize() function in the GA object determines the implicit range/domain assignments if the user doesn’t do so themselves.
6) The random_initialization() function is effectively the same, except there is now an if/else to determine if the user is using the built-in gene creation function or not. If they are, then pass the gene_input, gene_input_type, and current gene index as arguments to the gene function. If they are using their own function, random_initialization() functions exactly the same way as it does in the current master branch.
7) Based on all the settings mentioned above, the random_gene() function will create a value before passing it back to random_initialization().
