commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "AVIJIT BASAK (Jira)" <j...@apache.org>
Subject [jira] [Updated] (MATH-1618) Change in Existing Design
Date Sun, 01 Aug 2021 06:20:00 GMT

     [ 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: 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

 

  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) Introducing Elitism interface*: In current design ElitisticListPopulation introduces
couple of new operations related to elitism without declaring them in any abstraction. Elitism
interface would be introduced, which would be implemented by ElitisticListPopulation. 

Removed Components: None

New Components: Elitism

Affected Components: ElitisticListPopulation

*4) Change of Indirect encoding chromosome hierarchy*: The hierarchy of chromosome having
indirect encoding would be changed. Currently the design only considers permutation chromosome
for combinatorial optimization. The base interface is PermutationChromosome which is implemented
by RandomKey chromosome. A more appropriate name(like IndirectEncoding) of PermutationChromosome
can be used which will declare the decode() method. This interface will be implemented by
RandomKey chromosome. Tt would be more meaningful for any other new indirectly encoded chromosome
representing different domain to implement the new interface.

Removed Components: PermutationChromosome

New Components: IndirectEncoding

Affected Components: RandomKey

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

*6) 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.


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

Mime
View raw message