[jira] [Commented] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522535#comment-17522535 ] Gilles Sadowski commented on MATH-1618: --- I've just attached a few [Java source files|https://issues.apache.org/jira/secure/attachment/13042471/ga.zip]. They are mainly interfaces; for now, they are meant to illustrate an alternative approach with maximal decoupling of the steps that make up a "genetic algorithm" (GA). It's not tested (beyond compilation) and I've probably cut some corners (the devil is in the details), but the question is whether this can form the basis for the refactored GA functionality. Aside from the still missing implementations (actually the current concrete classes of the various chromosome representations, and their associated genetic operators, could probably be readily adapted). > Change in Existing Design > - > > Key: MATH-1618 > URL: https://issues.apache.org/jira/browse/MATH-1618 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Attachments: ga.zip > > > *1) Creation of abstraction for GeneticAlgorithm*: In order to have different > types of implementation for Genetic Algorithm like adaptive GA along with the > existing one, we need to introduce an abstraction and a hierarchy of > algorithm. AbstracttGeneticAlgorithm class needs to be implemented which > would be extended by all other Algorithm class. This would also ease any > future extension. > Removed Components: None > New Components: AbstractGeneticAlgorithm > Affected Components: GeneticAlgorithm > *2) Delegation of fitness calculation*: As per the current design Fitness > interface is implemented by chromosome class, which forces implementation of > fitness() method for any concrete chromosome. However this restricts the use > of same concrete chromosome implementation to be reused for different problem > domain. This inheritance based implementation should be replaced by > composition. A new interface FitnessCalculator would be introduced. An > instance of FitnessCalculator will be provided during creation of every > concrete chromosome. This will enable reuse of concrete chromosome classes in > different problem domain and hence improve extensibility and re-usability. > This will require addition of an argument for each factory method and > constructors. > Removed Components: Fitness > New Components: FitnessFunction > Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, > RandomKey > *3) Enable finer control for mutation and crossover probability*: Current > design uses the crossover and mutation probability at the chromosome level. > For finer control of mutation and crossover process the probability would be > managed within MutationPolicy and CrossoverPolicy implementations. > Probability would be passed as an argument to the respective operations. This > way the corresponding operations will be responsible for managing probability > and apply in convenient way. I have seen the controlling the mutation > probability at the allele(gene) level improves the exploring capability of > the optimization process and hence improves robustness. > Removed Components: None > New Components: None > Affected Components: MutationPolicy, CrossoverPolicy and all other > implementation classes > *4) Addition of new Simulation Stopping conditions*: New simulation stopping > conditions would be added based on population statistical characteristics. > The simulation can be stopped based on variations of population average > fitness or best fitness. These parameters are much better to represent nature > of convergence. This will improve robustness to a considerable extent. > Removed Components: None > New Components: UnchangedAvgFitness, UnchangedBestFitness, > Affected Components: SimulationStoppingCondition, GeneticAlgorithm, > FixedElapsedTime, FixedGenerationCount > *5) Introduction of Convergence listeners*: New convergence listener > interface and registry would be introduced to enable tracking of convergence. > Removed components: None > New Components: ConvergenceListener, ListenerRegistry, > PopulationStatisticalSummary > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm > *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of > Algorithm classes. Use of a separate ElitisticListPopulation class may not be > necessary. The method nextGeneration() in Population would accept the elitism > rate as an argument. Any concrete instance of Population would provide the > necessary implementation. > Removed components: ElitisticListPopulation > New Component: None > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population, > ListPopulation > *7)
[jira] [Commented] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17420061#comment-17420061 ] AVIJIT BASAK commented on MATH-1618: I have sent a note regarding the build issue to commons group. Need help to resolve this. > Change in Existing Design > - > > Key: MATH-1618 > URL: https://issues.apache.org/jira/browse/MATH-1618 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Attachments: image-2021-09-24-15-27-29-365.png > > > *1) Creation of abstraction for GeneticAlgorithm*: In order to have different > types of implementation for Genetic Algorithm like adaptive GA along with the > existing one, we need to introduce an abstraction and a hierarchy of > algorithm. AbstracttGeneticAlgorithm class needs to be implemented which > would be extended by all other Algorithm class. This would also ease any > future extension. > Removed Components: None > New Components: AbstractGeneticAlgorithm > Affected Components: GeneticAlgorithm > *2) Delegation of fitness calculation*: As per the current design Fitness > interface is implemented by chromosome class, which forces implementation of > fitness() method for any concrete chromosome. However this restricts the use > of same concrete chromosome implementation to be reused for different problem > domain. This inheritance based implementation should be replaced by > composition. A new interface FitnessCalculator would be introduced. An > instance of FitnessCalculator will be provided during creation of every > concrete chromosome. This will enable reuse of concrete chromosome classes in > different problem domain and hence improve extensibility and re-usability. > This will require addition of an argument for each factory method and > constructors. > Removed Components: Fitness > New Components: FitnessFunction > Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, > RandomKey > *3) Enable finer control for mutation and crossover probability*: Current > design uses the crossover and mutation probability at the chromosome level. > For finer control of mutation and crossover process the probability would be > managed within MutationPolicy and CrossoverPolicy implementations. > Probability would be passed as an argument to the respective operations. This > way the corresponding operations will be responsible for managing probability > and apply in convenient way. I have seen the controlling the mutation > probability at the allele(gene) level improves the exploring capability of > the optimization process and hence improves robustness. > Removed Components: None > New Components: None > Affected Components: MutationPolicy, CrossoverPolicy and all other > implementation classes > *4) Addition of new Simulation Stopping conditions*: New simulation stopping > conditions would be added based on population statistical characteristics. > The simulation can be stopped based on variations of population average > fitness or best fitness. These parameters are much better to represent nature > of convergence. This will improve robustness to a considerable extent. > Removed Components: None > New Components: UnchangedAvgFitness, UnchangedBestFitness, > Affected Components: SimulationStoppingCondition, GeneticAlgorithm, > FixedElapsedTime, FixedGenerationCount > *5) Introduction of Convergence listeners*: New convergence listener > interface and registry would be introduced to enable tracking of convergence. > Removed components: None > New Components: ConvergenceListener, ListenerRegistry, > PopulationStatisticalSummary > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm > *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of > Algorithm classes. Use of a separate ElitisticListPopulation class may not be > necessary. The method nextGeneration() in Population would accept the elitism > rate as an argument. Any concrete instance of Population would provide the > necessary implementation. > Removed components: ElitisticListPopulation > New Component: None > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population, > ListPopulation > *7) Introducing Hierarchy in Crossover and Mutation Operator*: Abstract > classes has been introduced for crossover and mutation operators. > Removed components: None > New Component: AbstractChromosomeCrossoverPolicy, > AbstractListChromosomeCrossoverPolicy, AbstractListChromosomeMutationPolicy > Affected Components: All concrete implementation classes for crossover and > mutation. > *8) Rename the method newFixedLengthChromosome() in > AbstractList**Chromosome***: The method newFixedLengthChromosome would be > renamed as newChromosome. As we are not considering
[jira] [Commented] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419716#comment-17419716 ] AVIJIT BASAK commented on MATH-1618: It will be a good idea to have ml-example module and put tsp in it. But for comparison we should use data from TSPLIB ([https://www.math.uwaterloo.ca/tsp/data/index.html).] > Change in Existing Design > - > > Key: MATH-1618 > URL: https://issues.apache.org/jira/browse/MATH-1618 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Attachments: image-2021-09-24-15-27-29-365.png > > > *1) Creation of abstraction for GeneticAlgorithm*: In order to have different > types of implementation for Genetic Algorithm like adaptive GA along with the > existing one, we need to introduce an abstraction and a hierarchy of > algorithm. AbstracttGeneticAlgorithm class needs to be implemented which > would be extended by all other Algorithm class. This would also ease any > future extension. > Removed Components: None > New Components: AbstractGeneticAlgorithm > Affected Components: GeneticAlgorithm > *2) Delegation of fitness calculation*: As per the current design Fitness > interface is implemented by chromosome class, which forces implementation of > fitness() method for any concrete chromosome. However this restricts the use > of same concrete chromosome implementation to be reused for different problem > domain. This inheritance based implementation should be replaced by > composition. A new interface FitnessCalculator would be introduced. An > instance of FitnessCalculator will be provided during creation of every > concrete chromosome. This will enable reuse of concrete chromosome classes in > different problem domain and hence improve extensibility and re-usability. > This will require addition of an argument for each factory method and > constructors. > Removed Components: Fitness > New Components: FitnessFunction > Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, > RandomKey > *3) Enable finer control for mutation and crossover probability*: Current > design uses the crossover and mutation probability at the chromosome level. > For finer control of mutation and crossover process the probability would be > managed within MutationPolicy and CrossoverPolicy implementations. > Probability would be passed as an argument to the respective operations. This > way the corresponding operations will be responsible for managing probability > and apply in convenient way. I have seen the controlling the mutation > probability at the allele(gene) level improves the exploring capability of > the optimization process and hence improves robustness. > Removed Components: None > New Components: None > Affected Components: MutationPolicy, CrossoverPolicy and all other > implementation classes > *4) Addition of new Simulation Stopping conditions*: New simulation stopping > conditions would be added based on population statistical characteristics. > The simulation can be stopped based on variations of population average > fitness or best fitness. These parameters are much better to represent nature > of convergence. This will improve robustness to a considerable extent. > Removed Components: None > New Components: UnchangedAvgFitness, UnchangedBestFitness, > Affected Components: SimulationStoppingCondition, GeneticAlgorithm, > FixedElapsedTime, FixedGenerationCount > *5) Introduction of Convergence listeners*: New convergence listener > interface and registry would be introduced to enable tracking of convergence. > Removed components: None > New Components: ConvergenceListener, ListenerRegistry, > PopulationStatisticalSummary > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm > *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of > Algorithm classes. Use of a separate ElitisticListPopulation class may not be > necessary. The method nextGeneration() in Population would accept the elitism > rate as an argument. Any concrete instance of Population would provide the > necessary implementation. > Removed components: ElitisticListPopulation > New Component: None > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population, > ListPopulation > *7) Introducing Hierarchy in Crossover and Mutation Operator*: Abstract > classes has been introduced for crossover and mutation operators. > Removed components: None > New Component: AbstractChromosomeCrossoverPolicy, > AbstractListChromosomeCrossoverPolicy, AbstractListChromosomeMutationPolicy > Affected Components: All concrete implementation classes for crossover and > mutation. > *8) Rename the method newFixedLengthChromosome() in > AbstractList**Chromosome***: The method
[jira] [Commented] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419693#comment-17419693 ] AVIJIT BASAK commented on MATH-1618: Thanks for the reply. The build has passed. The review can be started. Meanwhile, I have started to change the lambda expressions. > Change in Existing Design > - > > Key: MATH-1618 > URL: https://issues.apache.org/jira/browse/MATH-1618 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Attachments: image-2021-09-24-15-27-29-365.png > > > *1) Creation of abstraction for GeneticAlgorithm*: In order to have different > types of implementation for Genetic Algorithm like adaptive GA along with the > existing one, we need to introduce an abstraction and a hierarchy of > algorithm. AbstracttGeneticAlgorithm class needs to be implemented which > would be extended by all other Algorithm class. This would also ease any > future extension. > Removed Components: None > New Components: AbstractGeneticAlgorithm > Affected Components: GeneticAlgorithm > *2) Delegation of fitness calculation*: As per the current design Fitness > interface is implemented by chromosome class, which forces implementation of > fitness() method for any concrete chromosome. However this restricts the use > of same concrete chromosome implementation to be reused for different problem > domain. This inheritance based implementation should be replaced by > composition. A new interface FitnessCalculator would be introduced. An > instance of FitnessCalculator will be provided during creation of every > concrete chromosome. This will enable reuse of concrete chromosome classes in > different problem domain and hence improve extensibility and re-usability. > This will require addition of an argument for each factory method and > constructors. > Removed Components: Fitness > New Components: FitnessFunction > Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, > RandomKey > *3) Enable finer control for mutation and crossover probability*: Current > design uses the crossover and mutation probability at the chromosome level. > For finer control of mutation and crossover process the probability would be > managed within MutationPolicy and CrossoverPolicy implementations. > Probability would be passed as an argument to the respective operations. This > way the corresponding operations will be responsible for managing probability > and apply in convenient way. I have seen the controlling the mutation > probability at the allele(gene) level improves the exploring capability of > the optimization process and hence improves robustness. > Removed Components: None > New Components: None > Affected Components: MutationPolicy, CrossoverPolicy and all other > implementation classes > *4) Addition of new Simulation Stopping conditions*: New simulation stopping > conditions would be added based on population statistical characteristics. > The simulation can be stopped based on variations of population average > fitness or best fitness. These parameters are much better to represent nature > of convergence. This will improve robustness to a considerable extent. > Removed Components: None > New Components: UnchangedAvgFitness, UnchangedBestFitness, > Affected Components: SimulationStoppingCondition, GeneticAlgorithm, > FixedElapsedTime, FixedGenerationCount > *5) Introduction of Convergence listeners*: New convergence listener > interface and registry would be introduced to enable tracking of convergence. > Removed components: None > New Components: ConvergenceListener, ListenerRegistry, > PopulationStatisticalSummary > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm > *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of > Algorithm classes. Use of a separate ElitisticListPopulation class may not be > necessary. The method nextGeneration() in Population would accept the elitism > rate as an argument. Any concrete instance of Population would provide the > necessary implementation. > Removed components: ElitisticListPopulation > New Component: None > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population, > ListPopulation > *7) Introducing Hierarchy in Crossover and Mutation Operator*: Abstract > classes has been introduced for crossover and mutation operators. > Removed components: None > New Component: AbstractChromosomeCrossoverPolicy, > AbstractListChromosomeCrossoverPolicy, AbstractListChromosomeMutationPolicy > Affected Components: All concrete implementation classes for crossover and > mutation. > *8) Rename the method newFixedLengthChromosome() in > AbstractList**Chromosome***: The method newFixedLengthChromosome would be > renamed as
[jira] [Commented] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1741#comment-1741 ] Gilles Sadowski commented on MATH-1618: --- Although you've [modified|https://github.com/apache/commons-math/pull/197/commits/732b0d60826180ae0ff97217dea98eb36253c9e8] the indentation, be aware that other tools (e.g. SonarQube) will raise warning flags if you don't simplify such lambda expressions. > Change in Existing Design > - > > Key: MATH-1618 > URL: https://issues.apache.org/jira/browse/MATH-1618 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > > *1) Creation of abstraction for GeneticAlgorithm*: In order to have different > types of implementation for Genetic Algorithm like adaptive GA along with the > existing one, we need to introduce an abstraction and a hierarchy of > algorithm. AbstracttGeneticAlgorithm class needs to be implemented which > would be extended by all other Algorithm class. This would also ease any > future extension. > Removed Components: None > New Components: AbstractGeneticAlgorithm > Affected Components: GeneticAlgorithm > *2) Delegation of fitness calculation*: As per the current design Fitness > interface is implemented by chromosome class, which forces implementation of > fitness() method for any concrete chromosome. However this restricts the use > of same concrete chromosome implementation to be reused for different problem > domain. This inheritance based implementation should be replaced by > composition. A new interface FitnessCalculator would be introduced. An > instance of FitnessCalculator will be provided during creation of every > concrete chromosome. This will enable reuse of concrete chromosome classes in > different problem domain and hence improve extensibility and re-usability. > This will require addition of an argument for each factory method and > constructors. > Removed Components: Fitness > New Components: FitnessFunction > Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, > RandomKey > *3) Enable finer control for mutation and crossover probability*: Current > design uses the crossover and mutation probability at the chromosome level. > For finer control of mutation and crossover process the probability would be > managed within MutationPolicy and CrossoverPolicy implementations. > Probability would be passed as an argument to the respective operations. This > way the corresponding operations will be responsible for managing probability > and apply in convenient way. I have seen the controlling the mutation > probability at the allele(gene) level improves the exploring capability of > the optimization process and hence improves robustness. > Removed Components: None > New Components: None > Affected Components: MutationPolicy, CrossoverPolicy and all other > implementation classes > *4) Addition of new Simulation Stopping conditions*: New simulation stopping > conditions would be added based on population statistical characteristics. > The simulation can be stopped based on variations of population average > fitness or best fitness. These parameters are much better to represent nature > of convergence. This will improve robustness to a considerable extent. > Removed Components: None > New Components: UnchangedAvgFitness, UnchangedBestFitness, > Affected Components: SimulationStoppingCondition, GeneticAlgorithm, > FixedElapsedTime, FixedGenerationCount > *5) Introduction of Convergence listeners*: New convergence listener > interface and registry would be introduced to enable tracking of convergence. > Removed components: None > New Components: ConvergenceListener, ListenerRegistry, > PopulationStatisticalSummary > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm > *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of > Algorithm classes. Use of a separate ElitisticListPopulation class may not be > necessary. The method nextGeneration() in Population would accept the elitism > rate as an argument. Any concrete instance of Population would provide the > necessary implementation. > Removed components: ElitisticListPopulation > New Component: None > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population, > ListPopulation > *7) Introducing Hierarchy in Crossover and Mutation Operator*: Abstract > classes has been introduced for crossover and mutation operators. > Removed components: None > New Component: AbstractChromosomeCrossoverPolicy, > AbstractListChromosomeCrossoverPolicy, AbstractListChromosomeMutationPolicy > Affected Components: All concrete implementation classes for crossover and > mutation. > *8) Rename the method newFixedLengthChromosome() in >
[jira] [Commented] (MATH-1618) Change in Existing Design
[
https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417665#comment-17417665
]
Gilles Sadowski commented on MATH-1618:
---
*Note*: I've no GH account, so I'm
[commenting|https://github.com/apache/commons-math/pull/197#issuecomment-922933961]
here.
{quote}
{code}
private static class DummyChromosome extends AbstractChromosome {
DummyChromosome() {
super(c -> {
return counter++;
}, c -> {
return "0";
});
}
{code}
{quote}
Please try something (unstested) along:
{code}
private static class DummyChromosome extends AbstractChromosome {
DummyChromosome() {
super(c -> counter++, c -> "0");
}
{code}
> Change in Existing Design
> -
>
> Key: MATH-1618
> URL: https://issues.apache.org/jira/browse/MATH-1618
> Project: Commons Math
> Issue Type: Sub-task
>Affects Versions: 3.6.1
>Reporter: AVIJIT BASAK
>Priority: Major
>
> *1) Creation of abstraction for GeneticAlgorithm*: In order to have different
> types of implementation for Genetic Algorithm like adaptive GA along with the
> existing one, we need to introduce an abstraction and a hierarchy of
> algorithm. AbstracttGeneticAlgorithm class needs to be implemented which
> would be extended by all other Algorithm class. This would also ease any
> future extension.
> Removed Components: None
> New Components: AbstractGeneticAlgorithm
> Affected Components: GeneticAlgorithm
> *2) Delegation of fitness calculation*: As per the current design Fitness
> interface is implemented by chromosome class, which forces implementation of
> fitness() method for any concrete chromosome. However this restricts the use
> of same concrete chromosome implementation to be reused for different problem
> domain. This inheritance based implementation should be replaced by
> composition. A new interface FitnessCalculator would be introduced. An
> instance of FitnessCalculator will be provided during creation of every
> concrete chromosome. This will enable reuse of concrete chromosome classes in
> different problem domain and hence improve extensibility and re-usability.
> This will require addition of an argument for each factory method and
> constructors.
> Removed Components: Fitness
> New Components: FitnessFunction
> Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome,
> RandomKey
> *3) Enable finer control for mutation and crossover probability*: Current
> design uses the crossover and mutation probability at the chromosome level.
> For finer control of mutation and crossover process the probability would be
> managed within MutationPolicy and CrossoverPolicy implementations.
> Probability would be passed as an argument to the respective operations. This
> way the corresponding operations will be responsible for managing probability
> and apply in convenient way. I have seen the controlling the mutation
> probability at the allele(gene) level improves the exploring capability of
> the optimization process and hence improves robustness.
> Removed Components: None
> New Components: None
> Affected Components: MutationPolicy, CrossoverPolicy and all other
> implementation classes
> *4) Addition of new Simulation Stopping conditions*: New simulation stopping
> conditions would be added based on population statistical characteristics.
> The simulation can be stopped based on variations of population average
> fitness or best fitness. These parameters are much better to represent nature
> of convergence. This will improve robustness to a considerable extent.
> Removed Components: None
> New Components: UnchangedAvgFitness, UnchangedBestFitness,
> Affected Components: SimulationStoppingCondition, GeneticAlgorithm,
> FixedElapsedTime, FixedGenerationCount
> *5) Introduction of Convergence listeners*: New convergence listener
> interface and registry would be introduced to enable tracking of convergence.
> Removed components: None
> New Components: ConvergenceListener, ListenerRegistry,
> PopulationStatisticalSummary
> Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm
> *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of
> Algorithm classes. Use of a separate ElitisticListPopulation class may not be
> necessary. The method nextGeneration() in Population would accept the elitism
> rate as an argument. Any concrete instance of Population would provide the
> necessary implementation.
> Removed components: ElitisticListPopulation
> New Component: None
> Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population,
> ListPopulation
> *7) Introducing Hierarchy in Crossover and Mutation Operator*: Abstract
> classes has been introduced for crossover and
[jira] [Commented] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417660#comment-17417660 ] AVIJIT BASAK commented on MATH-1618: Here are the build errors. Need help to resolve these. https://github.com/apache/commons-math/pull/197#issuecomment-922933961 > Change in Existing Design > - > > Key: MATH-1618 > URL: https://issues.apache.org/jira/browse/MATH-1618 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > > *1) Creation of abstraction for GeneticAlgorithm*: In order to have different > types of implementation for Genetic Algorithm like adaptive GA along with the > existing one, we need to introduce an abstraction and a hierarchy of > algorithm. AbstracttGeneticAlgorithm class needs to be implemented which > would be extended by all other Algorithm class. This would also ease any > future extension. > Removed Components: None > New Components: AbstractGeneticAlgorithm > Affected Components: GeneticAlgorithm > *2) Delegation of fitness calculation*: As per the current design Fitness > interface is implemented by chromosome class, which forces implementation of > fitness() method for any concrete chromosome. However this restricts the use > of same concrete chromosome implementation to be reused for different problem > domain. This inheritance based implementation should be replaced by > composition. A new interface FitnessCalculator would be introduced. An > instance of FitnessCalculator will be provided during creation of every > concrete chromosome. This will enable reuse of concrete chromosome classes in > different problem domain and hence improve extensibility and re-usability. > This will require addition of an argument for each factory method and > constructors. > Removed Components: Fitness > New Components: FitnessFunction > Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, > RandomKey > *3) Enable finer control for mutation and crossover probability*: Current > design uses the crossover and mutation probability at the chromosome level. > For finer control of mutation and crossover process the probability would be > managed within MutationPolicy and CrossoverPolicy implementations. > Probability would be passed as an argument to the respective operations. This > way the corresponding operations will be responsible for managing probability > and apply in convenient way. I have seen the controlling the mutation > probability at the allele(gene) level improves the exploring capability of > the optimization process and hence improves robustness. > Removed Components: None > New Components: None > Affected Components: MutationPolicy, CrossoverPolicy and all other > implementation classes > *4) Addition of new Simulation Stopping conditions*: New simulation stopping > conditions would be added based on population statistical characteristics. > The simulation can be stopped based on variations of population average > fitness or best fitness. These parameters are much better to represent nature > of convergence. This will improve robustness to a considerable extent. > Removed Components: None > New Components: UnchangedAvgFitness, UnchangedBestFitness, > Affected Components: SimulationStoppingCondition, GeneticAlgorithm, > FixedElapsedTime, FixedGenerationCount > *5) Introduction of Convergence listeners*: New convergence listener > interface and registry would be introduced to enable tracking of convergence. > Removed components: None > New Components: ConvergenceListener, ListenerRegistry, > PopulationStatisticalSummary > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm > *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of > Algorithm classes. Use of a separate ElitisticListPopulation class may not be > necessary. The method nextGeneration() in Population would accept the elitism > rate as an argument. Any concrete instance of Population would provide the > necessary implementation. > Removed components: ElitisticListPopulation > New Component: None > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population, > ListPopulation > *7) Introducing Hierarchy in Crossover and Mutation Operator*: Abstract > classes has been introduced for crossover and mutation operators. > Removed components: None > New Component: AbstractChromosomeCrossoverPolicy, > AbstractListChromosomeCrossoverPolicy, AbstractListChromosomeMutationPolicy > Affected Components: All concrete implementation classes for crossover and > mutation. > *8) Rename the method newFixedLengthChromosome() in > AbstractList**Chromosome***: The method newFixedLengthChromosome would be > renamed as newChromosome. As we are not considering any variable length >
[jira] [Commented] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417654#comment-17417654 ] Gilles Sadowski commented on MATH-1618: --- Hi [~avijit.basak]. Thanks for your current work on the GA implementation. However please note again that the build does not pass; this is delaying review(s)... I noticed that you use TSP as benchmark/example; it makes me wonder whether to share code with the SOFM example application. IOW, there could be an "examples-ml" module (within the "commons-math-examples" module) with a TSP application that could launch the various algorithms and provide their respective performance. > Change in Existing Design > - > > Key: MATH-1618 > URL: https://issues.apache.org/jira/browse/MATH-1618 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > > *1) Creation of abstraction for GeneticAlgorithm*: In order to have different > types of implementation for Genetic Algorithm like adaptive GA along with the > existing one, we need to introduce an abstraction and a hierarchy of > algorithm. AbstracttGeneticAlgorithm class needs to be implemented which > would be extended by all other Algorithm class. This would also ease any > future extension. > Removed Components: None > New Components: AbstractGeneticAlgorithm > Affected Components: GeneticAlgorithm > *2) Delegation of fitness calculation*: As per the current design Fitness > interface is implemented by chromosome class, which forces implementation of > fitness() method for any concrete chromosome. However this restricts the use > of same concrete chromosome implementation to be reused for different problem > domain. This inheritance based implementation should be replaced by > composition. A new interface FitnessCalculator would be introduced. An > instance of FitnessCalculator will be provided during creation of every > concrete chromosome. This will enable reuse of concrete chromosome classes in > different problem domain and hence improve extensibility and re-usability. > This will require addition of an argument for each factory method and > constructors. > Removed Components: Fitness > New Components: FitnessFunction > Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, > RandomKey > *3) Enable finer control for mutation and crossover probability*: Current > design uses the crossover and mutation probability at the chromosome level. > For finer control of mutation and crossover process the probability would be > managed within MutationPolicy and CrossoverPolicy implementations. > Probability would be passed as an argument to the respective operations. This > way the corresponding operations will be responsible for managing probability > and apply in convenient way. I have seen the controlling the mutation > probability at the allele(gene) level improves the exploring capability of > the optimization process and hence improves robustness. > Removed Components: None > New Components: None > Affected Components: MutationPolicy, CrossoverPolicy and all other > implementation classes > *4) Addition of new Simulation Stopping conditions*: New simulation stopping > conditions would be added based on population statistical characteristics. > The simulation can be stopped based on variations of population average > fitness or best fitness. These parameters are much better to represent nature > of convergence. This will improve robustness to a considerable extent. > Removed Components: None > New Components: UnchangedAvgFitness, UnchangedBestFitness, > Affected Components: SimulationStoppingCondition, GeneticAlgorithm, > FixedElapsedTime, FixedGenerationCount > *5) Introduction of Convergence listeners*: New convergence listener > interface and registry would be introduced to enable tracking of convergence. > Removed components: None > New Components: ConvergenceListener, ListenerRegistry, > PopulationStatisticalSummary > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm > *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of > Algorithm classes. Use of a separate ElitisticListPopulation class may not be > necessary. The method nextGeneration() in Population would accept the elitism > rate as an argument. Any concrete instance of Population would provide the > necessary implementation. > Removed components: ElitisticListPopulation > New Component: None > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population, > ListPopulation > *7) Introducing Hierarchy in Crossover and Mutation Operator*: Abstract > classes has been introduced for crossover and mutation operators. > Removed components: None > New Component: AbstractChromosomeCrossoverPolicy, >
[jira] [Commented] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412234#comment-17412234 ] Gilles Sadowski commented on MATH-1618: --- bq. PR(#197) [Current code fails the build|https://app.travis-ci.com/github/apache/commons-math/builds/237115402]. Please attach a link to the PR (issue's menu -> "More" -> "Link"). > Change in Existing Design > - > > Key: MATH-1618 > URL: https://issues.apache.org/jira/browse/MATH-1618 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > > *1) Creation of abstraction for GeneticAlgorithm*: In order to have different > types of implementation for Genetic Algorithm like adaptive GA along with the > existing one, we need to introduce an abstraction and a hierarchy of > algorithm. AbstracttGeneticAlgorithm class needs to be implemented which > would be extended by all other Algorithm class. This would also ease any > future extension. > Removed Components: None > New Components: AbstractGeneticAlgorithm > Affected Components: GeneticAlgorithm > *2) Delegation of fitness calculation*: As per the current design Fitness > interface is implemented by chromosome class, which forces implementation of > fitness() method for any concrete chromosome. However this restricts the use > of same concrete chromosome implementation to be reused for different problem > domain. This inheritance based implementation should be replaced by > composition. A new interface FitnessCalculator would be introduced. An > instance of FitnessCalculator will be provided during creation of every > concrete chromosome. This will enable reuse of concrete chromosome classes in > different problem domain and hence improve extensibility and re-usability. > This will require addition of an argument for each factory method and > constructors. > Removed Components: Fitness > New Components: FitnessFunction > Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, > RandomKey > *3) Enable finer control for mutation and crossover probability*: Current > design uses the crossover and mutation probability at the chromosome level. > For finer control of mutation and crossover process the probability would be > managed within MutationPolicy and CrossoverPolicy implementations. > Probability would be passed as an argument to the respective operations. This > way the corresponding operations will be responsible for managing probability > and apply in convenient way. I have seen the controlling the mutation > probability at the allele(gene) level improves the exploring capability of > the optimization process and hence improves robustness. > Removed Components: None > New Components: None > Affected Components: MutationPolicy, CrossoverPolicy and all other > implementation classes > *4) Addition of new Simulation Stopping conditions*: New simulation stopping > conditions would be added based on population statistical characteristics. > The simulation can be stopped based on variations of population average > fitness or best fitness. These parameters are much better to represent nature > of convergence. This will improve robustness to a considerable extent. > Removed Components: None > New Components: UnchangedAvgFitness, UnchangedBestFitness, > Affected Components: SimulationStoppingCondition, GeneticAlgorithm, > FixedElapsedTime, FixedGenerationCount > *5) Introduction of Convergence listeners*: New convergence listener > interface and registry would be introduced to enable tracking of convergence. > Removed components: None > New Components: ConvergenceListener, ListenerRegistry, > PopulationStatisticalSummary > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm > *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of > Algorithm classes. Use of a separate ElitisticListPopulation class may not be > necessary. The method nextGeneration() in Population would accept the elitism > rate as an argument. Any concrete instance of Population would provide the > necessary implementation. > Removed components: ElitisticListPopulation > New Component: None > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population, > ListPopulation > *7) Introducing Hierarchy in Crossover and Mutation Operator*: Abstract > classes has been introduced for crossover and mutation operators. > Removed components: None > New Component: AbstractChromosomeCrossoverPolicy, > AbstractListChromosomeCrossoverPolicy, AbstractListChromosomeMutationPolicy > Affected Components: All concrete implementation classes for crossover and > mutation. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411941#comment-17411941 ] AVIJIT BASAK commented on MATH-1618: I have created the PR(#197). I think it will be easier to understand now. > Change in Existing Design > - > > Key: MATH-1618 > URL: https://issues.apache.org/jira/browse/MATH-1618 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > > *1) Creation of abstraction for GeneticAlgorithm*: In order to have different > types of implementation for Genetic Algorithm like adaptive GA along with the > existing one, we need to introduce an abstraction and a hierarchy of > algorithm. AbstracttGeneticAlgorithm class needs to be implemented which > would be extended by all other Algorithm class. This would also ease any > future extension. > Removed Components: None > New Components: AbstractGeneticAlgorithm > Affected Components: GeneticAlgorithm > *2) Delegation of fitness calculation*: As per the current design Fitness > interface is implemented by chromosome class, which forces implementation of > fitness() method for any concrete chromosome. However this restricts the use > of same concrete chromosome implementation to be reused for different problem > domain. This inheritance based implementation should be replaced by > composition. A new interface FitnessCalculator would be introduced. An > instance of FitnessCalculator will be provided during creation of every > concrete chromosome. This will enable reuse of concrete chromosome classes in > different problem domain and hence improve extensibility and re-usability. > This will require addition of an argument for each factory method and > constructors. > Removed Components: Fitness > New Components: FitnessFunction > Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, > RandomKey > *3) Enable finer control for mutation and crossover probability*: Current > design uses the crossover and mutation probability at the chromosome level. > For finer control of mutation and crossover process the probability would be > managed within MutationPolicy and CrossoverPolicy implementations. > Probability would be passed as an argument to the respective operations. This > way the corresponding operations will be responsible for managing probability > and apply in convenient way. I have seen the controlling the mutation > probability at the allele(gene) level improves the exploring capability of > the optimization process and hence improves robustness. > Removed Components: None > New Components: None > Affected Components: MutationPolicy, CrossoverPolicy and all other > implementation classes > *4) Addition of new Simulation Stopping conditions*: New simulation stopping > conditions would be added based on population statistical characteristics. > The simulation can be stopped based on variations of population average > fitness or best fitness. These parameters are much better to represent nature > of convergence. This will improve robustness to a considerable extent. > Removed Components: None > New Components: UnchangedAvgFitness, UnchangedBestFitness, > Affected Components: SimulationStoppingCondition, GeneticAlgorithm, > FixedElapsedTime, FixedGenerationCount > *5) Introduction of Convergence listeners*: New convergence listener > interface and registry would be introduced to enable tracking of convergence. > Removed components: None > New Components: ConvergenceListener, ListenerRegistry, > PopulationStatisticalSummary > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm > *6) Restructuring Elitism*: Elitism can be handled by the hierarchy of > Algorithm classes. Use of a separate ElitisticListPopulation class may not be > necessary. The method nextGeneration() in Population would accept the elitism > rate as an argument. Any concrete instance of Population would provide the > necessary implementation. > Removed components: ElitisticListPopulation > New Component: None > Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm, Population, > ListPopulation > *7) Introducing Hierarchy in Crossover and Mutation Operator*: Abstract > classes has been introduced for crossover and mutation operators -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1618) Change in Existing Design
[
https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394018#comment-17394018
]
Gilles Sadowski commented on MATH-1618:
---
bq. [...] {{AbstractGeneticAlgorithm}} [...]
With what functionality?
All the proposed enhancements seem fine, but they would be easier to grasp if
the textual explanation were accompanied with (pseudo-)code excerpts (and/or
pointers to source code).
> Change in Existing Design
> -
>
> Key: MATH-1618
> URL: https://issues.apache.org/jira/browse/MATH-1618
> Project: Commons Math
> Issue Type: Sub-task
>Affects Versions: 3.6.1
>Reporter: AVIJIT BASAK
>Priority: Major
>
> *1) Creation of abstraction for GeneticAlgorithm*: In order to have different
> types of implementation for Genetic Algorithm like adaptive GA along with the
> existing one, we need to introduce an abstraction and a hierarchy of
> algorithm. AbstracttGeneticAlgorithm class needs to be implemented which
> would be extended by all other Algorithm class. This would also ease any
> future extension.
> Removed Components: None
> New Components: AbstractGeneticAlgorithm
> Affected Components: GeneticAlgorithm
> *2) Delegation of fitness calculation*: As per the current design Fitness
> interface is implemented by chromosome class, which forces implementation of
> fitness() method for any concrete chromosome. However this restricts the use
> of same concrete chromosome implementation to be reused for different problem
> domain. This inheritance based implementation should be replaced by
> composition. A new interface FitnessCalculator would be introduced. An
> instance of FitnessCalculator will be provided during creation of every
> concrete chromosome. This will enable reuse of concrete chromosome classes in
> different problem domain and hence improve extensibility and re-usability.
> This will require addition of an argument for each factory method and
> constructors.
> Removed Components: Fitness
> New Components: FitnessCalculator
> Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome,
> RandomKey
> *3) Enable finer control for mutation and crossover probability*: Current
> design uses the crossover and mutation probability at the chromosome level.
> For finer control of mutation and crossover process the probability would be
> managed within MutationPolicy and CrossoverPolicy implementations.
> Probability would be passed as an argument to the respective operations. This
> way the corresponding operations will be responsible for managing probability
> and apply in convenient way. I have seen the controlling the mutation
> probability at the allele(gene) level improves the exploring capability of
> the optimization process and hence improves robustness.
> Removed Components: None
> New Components: None
> Affected Components: MutationPolicy, CrossoverPolicy and all other
> implementation classes
> *4) Addition of new Simulation Stopping conditions*: New simulation stopping
> conditions would be added based on population statistical characteristics.
> The simulation can be stopped based on variations of population average
> fitness or best fitness. These parameters are much better to represent nature
> of convergence. This will improve robustness to a considerable extent.
> Removed Components: None
> New Components: UnchangedAvgFitness, UnchangedBestFitness
> Affected Components: None
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
