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. I don't want to use the one
from math3 legacy component as that will include all other legacy
components too. If the commons-statistics component is an isolated one then
that can be re-used once released.
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?
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
