Hello. Le mer. 28 juil. 2021 à 10:23, Avijit Basak <avijit.ba...@gmail.com> a écrit : > > Hi > > I shall try to describe my proposed changes with proper context in > my next communication. Regarding the stats, I need a library that can be > used for any statistical calculation needed.
Are the calculations needed for the GA to work (e.g. as part of a stopping criterion), or are they only meant to inform the user (e.g. for computing current average fitness and the like)? In the latter case, (IIUC) I don't think that we need to introduce such a dependency: Couldn't "out-of-band" functionality be defined through a plugin infrastructure? > I don't want to use the one > from math3 legacy component as that will include all other legacy > components too. If you intend to improve the "genetics" package within the current "commons-math-legacy" module, you can use all the code in there, (including the "o.a.c.math4.stat" package, although that will make it more difficult to create a new module free of those dependencies. Please clarify what goal you are pursuing. > If the commons-statistics component is an isolated one then > that can be re-used once released. I don't understand what you mean. > It will be nice to have a library for plotting graph. Earlier I > used jFreeChart (Lesser GNU Public License), which works fine for this kind > of requirement. Any suggestion regarding this? If you suggest that a Commons component should depend on a plotting library, it's likely "no go". Would a GA implementation need this? Again, if the purpose is to follow progress of the computation, we should define appropriate interfaces to allow data collection in real time. How those are processed (e.g. plotting statistics of the current population) is probably out-of-scope. Regards, Gilles > > Thanks & Regards > --Avijit Basak > > > On Tue, 27 Jul 2021 at 19:33, Gilles Sadowski <gillese...@gmail.com> wrote: > > > 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 > > > > > > -- > Avijit Basak --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
