Hi
I have created two new subtasks for Jira *MATH-1563* to explain
the requirement of changes and a new JIRA MATH-1618
<https://issues.apache.org/jira/browse/MATH-1618>.
Let me know if that helps. We can continue the discussion here in
case of any queries.
Thanks & Regards
--Avijit Basak
On Wed, 28 Jul 2021 at 23:22, Gilles Sadowski <gillese...@gmail.com> wrote:
> 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
>
>
--
Avijit Basak
