You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Avijit Basak <av...@gmail.com> on 2021/07/27 07:14:45 UTC
[MATH][DESIGN] Design Discussion for Genetic Algorithm Library
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 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.
2) Can we have the stat module out of legacy component. This can be useful
to calculate population statistics if required.
Kindly share your thoughts.
Thanks & Regards
--Avijit Basak
Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library
Posted by Avijit Basak <av...@gmail.com>.
Hi All
I have created a pull request for task *MATH-1618* belonging to
*Jira** MATH-1563*. Kindly initiate the review. Please send a note if you
have any questions or concerns. Development is in progress for the next
task *MATH-1619*.
*URL:* https://github.com/apache/commons-math/pull/197
Thanks & Regards
--Avijit Basak
On Sun, 15 Aug 2021 at 23:17, Gilles Sadowski <gi...@gmail.com> wrote:
> Le dim. 15 août 2021 à 15:48, Avijit Basak <av...@gmail.com> a
> écrit :
> >
> > Hi
> >
> > As mentioned earlier I need to use descriptive statistics in
> > *genetics* module as part of *math4* release. This will be required for
> > checking convergence status, probability generation. This can also be
> used
> > for streaming current population conditions to interested listeners.
> > Currently, we have a DescriptiveStatistics class as part of math4.legacy
> > module. Is there any plan to develop a new statistics module like
> neuralnet
> > and genetics?
>
> Not exactly: Refactored statistics utilities should find a home in the
> the new "Commons Statistics" component.[1]
>
> > If not what is the way to proceed forward. Kindly guide me in
> > this regard.
>
> There are several ways forward:
> 1. You contribute to start work on a "commons-statistics-descriptive"
> maven module in the component mentioned above. ["Commons Math"
> can depend on that component's modules.]
> 2. You make modifications to the GA functionality inside the current
> "o.a.c.m.legacy.genetics" package. [I'd still advise that we define
> interfaces to whatever functionality (like descriptive statistics) should
> ultimately be implemented somewhere else.]
> 3. You create a new "commons-math-ga" module that does not depend
> on the "commons-math-legacy" module. [That would imply creating an
> "internal" package (where you can copy anything you need) whose
> contents will not be part of the official API (i.e. users must not rely on
> it being stable across even minor releases).]
>
>
> Regards,
> Gilles
>
> [1] https://commons.apache.org/proper/commons-statistics
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Avijit Basak
Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library
Posted by Gilles Sadowski <gi...@gmail.com>.
Le dim. 15 août 2021 à 15:48, Avijit Basak <av...@gmail.com> a écrit :
>
> Hi
>
> As mentioned earlier I need to use descriptive statistics in
> *genetics* module as part of *math4* release. This will be required for
> checking convergence status, probability generation. This can also be used
> for streaming current population conditions to interested listeners.
> Currently, we have a DescriptiveStatistics class as part of math4.legacy
> module. Is there any plan to develop a new statistics module like neuralnet
> and genetics?
Not exactly: Refactored statistics utilities should find a home in the
the new "Commons Statistics" component.[1]
> If not what is the way to proceed forward. Kindly guide me in
> this regard.
There are several ways forward:
1. You contribute to start work on a "commons-statistics-descriptive"
maven module in the component mentioned above. ["Commons Math"
can depend on that component's modules.]
2. You make modifications to the GA functionality inside the current
"o.a.c.m.legacy.genetics" package. [I'd still advise that we define
interfaces to whatever functionality (like descriptive statistics) should
ultimately be implemented somewhere else.]
3. You create a new "commons-math-ga" module that does not depend
on the "commons-math-legacy" module. [That would imply creating an
"internal" package (where you can copy anything you need) whose
contents will not be part of the official API (i.e. users must not rely on
it being stable across even minor releases).]
Regards,
Gilles
[1] https://commons.apache.org/proper/commons-statistics
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library
Posted by Avijit Basak <av...@gmail.com>.
Hi
As mentioned earlier I need to use descriptive statistics in
*genetics* module as part of *math4* release. This will be required for
checking convergence status, probability generation. This can also be used
for streaming current population conditions to interested listeners.
Currently, we have a DescriptiveStatistics class as part of math4.legacy
module. Is there any plan to develop a new statistics module like neuralnet
and genetics? If not what is the way to proceed forward. Kindly guide me in
this regard.
Thanks & Regards
--Avijit Basak
On Sun, 8 Aug 2021 at 19:14, Gilles Sadowski <gi...@gmail.com> wrote:
> Hello.
>
> Le dim. 8 août 2021 à 07:22, Avijit Basak <av...@gmail.com> a
> écrit :
> >
> > Hi All
> >
> > I have started to work in genetic module.
>
> Great!
>
> > I want to push the new
> > module as part of a new feature branch "*feature/MATH-1563*". Changes
> > include mostly the existing code and modfication due to the new Exception
> > class. I have encountered the following error which indicates my Github
> Id "
> > *avijitbasak*" is not permitted to check-in code in the repository.
>
> Indeed, not all GitHub users are allowed to modify an ASF's project
> repository. ;-)
>
> > Could
> > anyone kindly grant me access to the repository. Let me know if I need to
> > do anything else regarding this.
>
> Only ASF committers[1] are given write access.
> For a contributor who is not (yet) a committer, the (nowadays[2]) usual way
> to suggest changes is through GitHub pull requests (i.e. you have to
> "clone"
> the repository into your projects' GH space and modify there).
>
> Regards,
> Gilles
>
> [1] https://www.apache.org/foundation/how-it-works.html#roles
> [2] The alternative is uploading patches to the issue-tracking system:
> https://commons.apache.org/patches.html
>
> > [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Avijit Basak
Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le dim. 8 août 2021 à 07:22, Avijit Basak <av...@gmail.com> a écrit :
>
> Hi All
>
> I have started to work in genetic module.
Great!
> I want to push the new
> module as part of a new feature branch "*feature/MATH-1563*". Changes
> include mostly the existing code and modfication due to the new Exception
> class. I have encountered the following error which indicates my Github Id "
> *avijitbasak*" is not permitted to check-in code in the repository.
Indeed, not all GitHub users are allowed to modify an ASF's project
repository. ;-)
> Could
> anyone kindly grant me access to the repository. Let me know if I need to
> do anything else regarding this.
Only ASF committers[1] are given write access.
For a contributor who is not (yet) a committer, the (nowadays[2]) usual way
to suggest changes is through GitHub pull requests (i.e. you have to "clone"
the repository into your projects' GH space and modify there).
Regards,
Gilles
[1] https://www.apache.org/foundation/how-it-works.html#roles
[2] The alternative is uploading patches to the issue-tracking system:
https://commons.apache.org/patches.html
> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library
Posted by Avijit Basak <av...@gmail.com>.
Hi All
I have started to work in genetic module. I want to push the new
module as part of a new feature branch "*feature/MATH-1563*". Changes
include mostly the existing code and modfication due to the new Exception
class. I have encountered the following error which indicates my Github Id "
*avijitbasak*" is not permitted to check-in code in the repository. Could
anyone kindly grant me access to the repository. Let me know if I need to
do anything else regarding this.
git.exe push --progress "origin" feature/MATH-1563
remote: Permission to apache/commons-math.git denied to avijitbasak.
fatal: unable to access '*https://github.com/apache/commons-math.git/
<https://github.com/apache/commons-math.git/>*': The requested URL returned
error: *403*
Thanks & Regards
--Avijit Basak
On Sun, 8 Aug 2021 at 10:49, Avijit Basak <av...@gmail.com> wrote:
> 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 <gi...@gmail.com>
> wrote:
>
>> Hello.
>>
>> Le mer. 28 juil. 2021 à 10:23, Avijit Basak <av...@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 <gi...@gmail.com>
>> wrote:
>> >
>> > > Hello.
>> > >
>> > > Le mar. 27 juil. 2021 à 09:15, Avijit Basak <av...@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-unsubscribe@commons.apache.org
>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > >
>> >
>> > --
>> > Avijit Basak
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> --
> Avijit Basak
>
--
Avijit Basak
Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library
Posted by Avijit Basak <av...@gmail.com>.
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 <gi...@gmail.com> wrote:
> Hello.
>
> Le mer. 28 juil. 2021 à 10:23, Avijit Basak <av...@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 <gi...@gmail.com>
> wrote:
> >
> > > Hello.
> > >
> > > Le mar. 27 juil. 2021 à 09:15, Avijit Basak <av...@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > --
> > Avijit Basak
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Avijit Basak
Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le mer. 28 juil. 2021 à 10:23, Avijit Basak <av...@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 <gi...@gmail.com> wrote:
>
> > Hello.
> >
> > Le mar. 27 juil. 2021 à 09:15, Avijit Basak <av...@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> --
> Avijit Basak
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library
Posted by Avijit Basak <av...@gmail.com>.
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 <gi...@gmail.com> wrote:
> Hello.
>
> Le mar. 27 juil. 2021 à 09:15, Avijit Basak <av...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Avijit Basak
Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le mar. 27 juil. 2021 à 09:15, Avijit Basak <av...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org