You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "AVIJIT BASAK (Jira)" <ji...@apache.org> on 2021/09/08 10:32:00 UTC

[jira] [Updated] (MATH-1618) Change in Existing Design

     [ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

AVIJIT BASAK updated MATH-1618:
-------------------------------
    Description: 
*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

  was:
*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, PopulationStatisticalSummary

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

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


> 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)