Hello. Le mar. 27 juil. 2021 à 09:15, Avijit Basak <avijit.ba...@gmail.com> a écrit : > > Hi All > > Please find the proposed changes for the Genetic Algorithm library in > commons.maths. > Changes in Model: > 1) GeneticAlgorithm class is broken into a hierarchy to accommodate commons > implementation in an Abstract class AbstractGeneticAlgorithm. New > AdaptiveGeneticAlgorithm class has also been introduced. > 2) Introduced Elitism interface which is implemented by > ElitisticListPopulation. > 3) Interface Fitness has been removed. > 4) Interface FitnessCalculator has been introduced. > 5) Chromosome has been updated with FitnessCalculator interface and accessor. > 6) Operations in AbstractChromosome has been updated with FitnessCalculator > as interface. > 7) New BinaryChromosome class has been added. > 8) Interface PermutationChromosome has been replaced by > IndirectlyEncodedChromosome as the interface primarily represents chromosomes > with indirect encoding. A more appropriate name can be suggested. > 9) RandomKey class operations have been updated with FitnessCalculator. > 10) I would like to include a new class PermutationChromosome as we have > corresponding crossover operators like OrderedCrossover. > 11) crossover method in CrossoverPolicy interface has been updated with > additional argument probability to support dynamic probability generation. > This would impact all implementation classes. > 12) mutate method in MutationPolicy has been added another argument > probability to support dynamic probability generation. This would impact all > implementation classes. > 13) Two new evolution StoppingCondition has been added UnchangedAvgFitness > and UnchangedBestFitness. > 14) An interface ProbabilityGenerator has been introduced with few selective > implementations to be used by AdaptiveGeneticAlgorithm class. The signature > of the probability generation method has been kept generic to keep strategies > interchangeable.
I'd have a hard time commenting as we mostly miss the context: AFAIK, nobody here has ever used CM's GA implementation and nobody knows how its design structure should be changed in order to improve its * usability, * performance, * robustness, * extensibility, or * maintenance; hence the listing of changes is not very useful without some hint as to why things are to be modified, removed or added (e.g. pointing to shortcomings, missing features, performance bottlenecks, and so on; and create a JIRA report for each of them). Actually, I understand that it might be a tedious task, and probably not worth the modest feedback which you may expect in return. So the best course of action is perhaps to implement the new design as you see fit, and then show (through applications in "examples" module) how it solves selected problems. Doing so, you could keep us informed of your progress through commenting in the appropriate JIRA report(s) and a link to an up-to-date PR. > I have few more queries related to repository structure. > 1) Do we need to keep package name as math4 and not math. Using a version-independent name would ease version migration for developers for future releases. Commons has a strict policy of backwards compatibility of minor releases. Changing the top-level package's name is done in every major release in order to avoid JAR hell. > 2) Can we have the stat module out of legacy component. Are you on to fix all the reported issues? > This can be useful to calculate population statistics if required. You are certainly welcome to refactor the parts of the "o.a.c.m.stat" package which would be of interest for that purpose. Please note that redesign statistical functionalities should be ported to the "Commons Statistics" component.[1] Regards, Gilles [1] https://commons.apache.org/proper/commons-statistics/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
