[jira] [Commented] (MATH-1643) Implementation of multi-threading in Genetic Algorithm and parallel GA with multiple populations.
[ https://issues.apache.org/jira/browse/MATH-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516669#comment-17516669 ] AVIJIT BASAK commented on MATH-1643: Modified the Jira description. Implementation is as per current description. > Implementation of multi-threading in Genetic Algorithm and parallel GA with > multiple populations. > - > > Key: MATH-1643 > URL: https://issues.apache.org/jira/browse/MATH-1643 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Fix For: 4.0 > > > Current implementation of Genetic Algorithm does not use *multi-threading* > during optimization process. A multi-threading approach would be required to > enable usage of multiple cores of user CPU. This would also enable > implementation of *parallel GA* with multiple populations where each > population would converge independently, and the list of converged > populations will be returned to caller. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MATH-1643) Implementation of multi-threading in Genetic Algorithm and parallel GA with multiple populations.
[ https://issues.apache.org/jira/browse/MATH-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1643: --- Description: Current implementation of Genetic Algorithm does not use *multi-threading* during optimization process. A multi-threading approach would be required to enable usage of multiple cores of user CPU. This would also enable implementation of *parallel GA* with multiple populations where each population would converge independently, and the list of converged populations will be returned to caller. (was: Current implementation of Genetic Algorithm does not use *multi-threading* during optimization process. A multi-threading approach would be required to enable usage of multiple cores of user CPU. This would also enable implementation of *parallel GA* with multiple populations where each population would converge independently, and the list of converged population will be returned to caller.) > Implementation of multi-threading in Genetic Algorithm and parallel GA with > multiple populations. > - > > Key: MATH-1643 > URL: https://issues.apache.org/jira/browse/MATH-1643 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Fix For: 4.0 > > > Current implementation of Genetic Algorithm does not use *multi-threading* > during optimization process. A multi-threading approach would be required to > enable usage of multiple cores of user CPU. This would also enable > implementation of *parallel GA* with multiple populations where each > population would converge independently, and the list of converged > populations will be returned to caller. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MATH-1643) Implementation of multi-threading in Genetic Algorithm and parallel GA with multiple populations.
[ https://issues.apache.org/jira/browse/MATH-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1643: --- Description: Current implementation of Genetic Algorithm does not use *multi-threading* during optimization process. A multi-threading approach would be required to enable usage of multiple cores of user CPU. This would also enable implementation of *parallel GA* with multiple populations where each population would converge independently, and the list of converged population will be returned to caller. (was: Current implementation of Genetic Algorithm does not use *multi-threading* during optimization process. A multi-threading approach would be required to enable usage of multiple cores of user CPU. This would also enable implementation of *parallel GA* with multiple populations where each population would converge independently, and the best result will be accepted as a solution.) > Implementation of multi-threading in Genetic Algorithm and parallel GA with > multiple populations. > - > > Key: MATH-1643 > URL: https://issues.apache.org/jira/browse/MATH-1643 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Fix For: 4.0 > > > Current implementation of Genetic Algorithm does not use *multi-threading* > during optimization process. A multi-threading approach would be required to > enable usage of multiple cores of user CPU. This would also enable > implementation of *parallel GA* with multiple populations where each > population would converge independently, and the list of converged > population will be returned to caller. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MATH-1643) Implementation of multi-threading in Genetic Algorithm and parallel GA with multiple populations.
AVIJIT BASAK created MATH-1643: -- Summary: Implementation of multi-threading in Genetic Algorithm and parallel GA with multiple populations. Key: MATH-1643 URL: https://issues.apache.org/jira/browse/MATH-1643 Project: Commons Math Issue Type: Sub-task Affects Versions: 3.6.1 Reporter: AVIJIT BASAK Fix For: 4.0 Current implementation of Genetic Algorithm does not use *multi-threading* during optimization process. A multi-threading approach would be required to enable usage of multiple cores of user CPU. This would also enable implementation of *parallel GA* with multiple populations where each population would converge independently, and the best result will be accepted as a solution. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MATH-1637) Improvement of data structure for Binary Chromosome
[ https://issues.apache.org/jira/browse/MATH-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1637: --- Description: {*}Improvement of BinaryChromosome data structure{*}: Currently binary chromosome has been implemented as a list of Integer data where each binary bit is represent as Integer. This reduces the memory utilization to a considerable extent as 31 out of 32 bits are wasted. This needs to be implemented as an array of long data type with each long data element representing 64 binary alleles following the article "https://arxiv.org/abs/2103.04751;. This would improve the memory utilization close to 100%. This will also impact the corresponding mutation and crossover operations. Removed Components: none New Components: OnePointBinaryCrossover Affected Components: BinaryChromosome, BinaryMutation was: {*}Improvement of BinaryChromosome data structure{*}: Currently binary chromosome has been implemented as a list of Integer data where each binary bit is represent as Integer. This reduces the memory utilization to a considerable extent as 31 out of 32 bits are wasted. This needs to be implemented as an array of long data type with each long representing 64 binary alleles. This would improve the memory utilization to 100%. This will also impact the corresponding mutation and crossover operations. Removed Components: none New Components: OnePointBinaryCrossover Affected Components: BinaryChromosome, BinaryMutation > Improvement of data structure for Binary Chromosome > --- > > Key: MATH-1637 > URL: https://issues.apache.org/jira/browse/MATH-1637 > Project: Commons Math > Issue Type: Sub-task >Reporter: AVIJIT BASAK >Priority: Major > > {*}Improvement of BinaryChromosome data structure{*}: Currently binary > chromosome has been implemented as a list of Integer data where each binary > bit is represent as Integer. This reduces the memory utilization to a > considerable extent as 31 out of 32 bits are wasted. This needs to be > implemented as an array of long data type with each long data element > representing 64 binary alleles following the article > "https://arxiv.org/abs/2103.04751;. This would improve the memory utilization > close to 100%. This will also impact the corresponding mutation and > crossover operations. > Removed Components: none > New Components: OnePointBinaryCrossover > Affected Components: BinaryChromosome, BinaryMutation -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MATH-1620) Changes in Design and Data Structure of GeneticAlgorithm component
[ https://issues.apache.org/jira/browse/MATH-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK closed MATH-1620. -- Resolution: Duplicate This proposal has been incorporated as part of Jira MATH-1563 > Changes in Design and Data Structure of GeneticAlgorithm component > -- > > Key: MATH-1620 > URL: https://issues.apache.org/jira/browse/MATH-1620 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Minor > > I would like to propose following changes for GeneticAlgorithm library. > *1) 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 > *2) 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 > *3) Improvement of BinaryChromosome data structure*: Currently binary > chromosome has been implemented as a list of Integer data where each binary > bit is represent as Integer. This reduces the memory utilization to a > considerable extent as 31 out of 32 bits are wasted. This needs to be > implemented as an array of int data type with each integer representing 32 > binary alleles. This would improve the memory utilization to 100%. This will > also impact the corresponding mutation and crossover operations. > Removed Components: o.a.c.m.g.BinaryChromosome > New Components: BinaryChromosome, OnePointBinaryCrossover, FlipMutation > Affected Components: None > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MATH-1637) Improvement of data structure for Binary Chromosome
AVIJIT BASAK created MATH-1637: -- Summary: Improvement of data structure for Binary Chromosome Key: MATH-1637 URL: https://issues.apache.org/jira/browse/MATH-1637 Project: Commons Math Issue Type: Sub-task Reporter: AVIJIT BASAK {*}Improvement of BinaryChromosome data structure{*}: Currently binary chromosome has been implemented as a list of Integer data where each binary bit is represent as Integer. This reduces the memory utilization to a considerable extent as 31 out of 32 bits are wasted. This needs to be implemented as an array of long data type with each long representing 64 binary alleles. This would improve the memory utilization to 100%. This will also impact the corresponding mutation and crossover operations. Removed Components: none New Components: OnePointBinaryCrossover Affected Components: BinaryChromosome, BinaryMutation -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1563: --- Attachment: chromosome hierarchy.png > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > Attachments: GA-Model.uxf, GA-Model.uxf, GA-OperatorModel.uxf, > GA-OperatorModel.uxf, GA-Overview.uxf, GA-Overview.uxf, chromosome > hierarchy.png > > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[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: --- Attachment: (was: image-2021-09-24-15-27-29-365.png) > 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 > chromosome and chromosome representation is immutable in > AbstractListChromosome we don't need any explicit
[jira] [Issue Comment Deleted] (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: --- Comment: was deleted (was: 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=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] [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. 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 chromosome and chromosome representation is immutable in AbstractListChromosome we don't need any explicit mention of the phrase 'FixedLength' as part of the method. *9) Introduction of Decoder and Phenotype:* Phenotype has been introduced as Generic. Decoder has been also introduced to transform the chromosome genotype to phenotype. The phenotype would be used for majority of computation like calculation of fitness, chromosome comparison etc. This is major design change from the previous model. This will enable same genotype to be used for both direct and indirect encoding of
[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] [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: --- Attachment: image-2021-09-24-15-27-29-365.png > 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 any variable length > chromosome and chromosome representation is immutable in >
[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. 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 chromosome and chromosome representation is immutable in AbstractListChromosome we don't need any explicit mention of the phrase 'FixedLength' as part of the method. *9) Introduction of Decoder and Phenotype:* Phenotype has been introduced as Generic. Decoder has been also introduced to transform the chromosome genotype to phenotype. The phenotype would be used for majority of computation like calculation of fitness, chromosome comparison etc. This is major design change from the previous model. This will enable same genotype to be used for both direct and indirect encoding of
[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] [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. 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 chromosome and chromosome representation is immutable in AbstractListChromosome we don't need any explicit mention of the phrase 'FixedLength' as part of the method. *9) Introduction of Decoder and Phenotype:* Phenotype has been introduced as Generic. Decoder has been also introduced to transform the chromosome genotype to phenotype. The phenotype would be used for majority of computation like calculation of fitness, chromosome comparison etc. This is major design change from the previous model. This will enable same genotype to be used for both direct and indirect encoding of
[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. 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 chromosome and chromosome representation is immutable in AbstractListChromosome we don't need any explicit mention of the phrase 'FixedLength' as part of the method. 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
[jira] [Comment Edited] (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 edited comment on MATH-1618 at 9/8/21, 2:05 PM: - I am creating two concrete classes for GeneticAlgorithm implementation. The existing one should be there for simple GA. A new class should also be introduced for adaptive GA which will be more versatile. An abstract class AbstractGeneticAlgorithm is introduced to represent the abstraction for both of them and will contain common properties and operations. I have created the PR(#197) for this task. was (Author: avijit.basak): 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. > Removed components: None >
[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. Removed components: None New Component: AbstractChromosomeCrossoverPolicy, AbstractListChromosomeCrossoverPolicy, AbstractListChromosomeMutationPolicy Affected Components: All concrete implementation classes for crossover and mutation. 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
[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] [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
[jira] [Updated] (MATH-1619) Implementation of Adaptive Probability Generation
[ https://issues.apache.org/jira/browse/MATH-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1619: --- Description: An Adaptive Probability Generation has been proposed as part of the Jira. A new class AdaptiveGeneticAlgorithm should be introduced as an implementation, which would extend the AbstractGeneticAlgorithm class. A new ProbabilityGenerator interface would be introduced to enable configurable probability generation strategy. The implementation of the ProbabilityGenerator interface for crossover and mutation probability generation will be provided during creation of AdaptiveGeneticAlgorithm instance. There can be different probability generation strategy like based on chromosome rank, no of generations passed etc, population statistics\al parameters. The design of ProbabilityGenerator should consider for arguments like chromosome rank, population stats etc. to enable interchangeable probability generation by the same AdaptiveGeneticalgorithm class. Removed Components: None New Components: AdaptiveGeneticAlgorithm, CrossoverProbabilityGenerator, MutationProbabilityGenerator ConstantCrossoverProbabilityGenerator, ConstantMutationProbabilityGenerator, LinearAdaptiveCrossoverProbabilityGenerator, LinearAdaptiveMutationProbabilityGenerator, LinearAdaptiveRandomCrossoverProbabilityGenerator, LinearAdaptiveRandomMutationProbabilityGenerator, TimeVaryingLinearAdaptiveCrossoverProbabilityGenerator, TimeVaryingLinearAdaptiveMutationProbabilityGenerator, Affected components: None was: An Adaptive Probability Generation has been proposed as part of the Jira. A new class AdaptiveGeneticAlgorithm should be introduced as an implementation, which would extend the AbstractGeneticAlgorithm class. A new ProbabilityGenerator interface would be introduced to enable configurable probability generation strategy. The implementation of the ProbabilityGenerator interface for crossover and mutation probability generation will be provided during creation of AdaptiveGeneticAlgorithm instance. There can be different probability generation strategy like based on chromosome rank, no of generations passed etc, population statistics\al parameters. The design of ProbabilityGenerator should consider for arguments like chromosome rank, population stats etc. to enable interchangeable probability generation by the same AdaptiveGeneticalgorithm class. Removed Components: None New Components: AdaptiveGeneticAlgorithm, ProbabilityGenerator, ConstantProbabilityGenerator, LinearAdaptiveProbabilityGenerator, TimeVaryingLinearAdaptiveProbabilityGenerator Affected components: None > Implementation of Adaptive Probability Generation > - > > Key: MATH-1619 > URL: https://issues.apache.org/jira/browse/MATH-1619 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > > An Adaptive Probability Generation has been proposed as part of the Jira. A > new class AdaptiveGeneticAlgorithm should be introduced as an implementation, > which would extend the AbstractGeneticAlgorithm class. A new > ProbabilityGenerator interface would be introduced to enable configurable > probability generation strategy. The implementation of the > ProbabilityGenerator interface for crossover and mutation probability > generation will be provided during creation of AdaptiveGeneticAlgorithm > instance. There can be different probability generation strategy like based > on chromosome rank, no of generations passed etc, population statistics\al > parameters. The design of ProbabilityGenerator should consider for arguments > like chromosome rank, population stats etc. to enable interchangeable > probability generation by the same AdaptiveGeneticalgorithm class. > Removed Components: None > New Components: AdaptiveGeneticAlgorithm, CrossoverProbabilityGenerator, > MutationProbabilityGenerator ConstantCrossoverProbabilityGenerator, > ConstantMutationProbabilityGenerator, > LinearAdaptiveCrossoverProbabilityGenerator, > LinearAdaptiveMutationProbabilityGenerator, > LinearAdaptiveRandomCrossoverProbabilityGenerator, > LinearAdaptiveRandomMutationProbabilityGenerator, > TimeVaryingLinearAdaptiveCrossoverProbabilityGenerator, > TimeVaryingLinearAdaptiveMutationProbabilityGenerator, > Affected components: None > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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: 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 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
[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: 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 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
[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: 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 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
[jira] [Created] (MATH-1620) Changes in Design and Data Structure of GeneticAlgorithm component
AVIJIT BASAK created MATH-1620: -- Summary: Changes in Design and Data Structure of GeneticAlgorithm component Key: MATH-1620 URL: https://issues.apache.org/jira/browse/MATH-1620 Project: Commons Math Issue Type: Improvement Affects Versions: 3.6.1 Reporter: AVIJIT BASAK I would like to propose following changes for GeneticAlgorithm library. *1) 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 *2) 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 *3) Improvement of BinaryChromosome data structure*: Currently binary chromosome has been implemented as a list of Integer data where each binary bit is represent as Integer. This reduces the memory utilization to a considerable extent as 31 out of 32 bits are wasted. This needs to be implemented as an array of int data type with each integer representing 32 binary alleles. This would improve the memory utilization to 100%. This will also impact the corresponding mutation and crossover operations. Removed Components: o.a.c.m.g.BinaryChromosome New Components: BinaryChromosome, OnePointBinaryCrossover, FlipMutation Affected Components: None -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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: 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
[jira] [Created] (MATH-1619) Implementation of Adaptive Probability Generation
AVIJIT BASAK created MATH-1619: -- Summary: Implementation of Adaptive Probability Generation Key: MATH-1619 URL: https://issues.apache.org/jira/browse/MATH-1619 Project: Commons Math Issue Type: Sub-task Affects Versions: 3.6.1 Reporter: AVIJIT BASAK An Adaptive Probability Generation has been proposed as part of the Jira. A new class AdaptiveGeneticAlgorithm should be introduced as an implementation, which would extend the AbstractGeneticAlgorithm class. A new ProbabilityGenerator interface would be introduced to enable configurable probability generation strategy. The implementation of the ProbabilityGenerator interface for crossover and mutation probability generation will be provided during creation of AdaptiveGeneticAlgorithm instance. There can be different probability generation strategy like based on chromosome rank, no of generations passed etc, population statistics\al parameters. The design of ProbabilityGenerator should consider for arguments like chromosome rank, population stats etc. to enable interchangeable probability generation by the same AdaptiveGeneticalgorithm class. Removed Components: None New Components: AdaptiveGeneticAlgorithm, ProbabilityGenerator, ConstantProbabilityGenerator, LinearAdaptiveProbabilityGenerator, TimeVaryingLinearAdaptiveProbabilityGenerator Affected components: None -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MATH-1618) Change in Existing Design
AVIJIT BASAK created MATH-1618: -- Summary: 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 *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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17381077#comment-17381077 ] AVIJIT BASAK commented on MATH-1563: Updated the previous model. Changes are listed below: 1) AdaptiveGeneticAlgorithm class is introduced 2) Introduced FitnessCalculator interface for chromosome and removed Fitness interface. Modified diagrams are attached below: [^GA-Overview.uxf] [^GA-Model.uxf] > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > Attachments: GA-Model.uxf, GA-Model.uxf, GA-OperatorModel.uxf, > GA-OperatorModel.uxf, GA-Overview.uxf, GA-Overview.uxf > > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1563: --- Attachment: GA-OperatorModel.uxf > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > Attachments: GA-Model.uxf, GA-Model.uxf, GA-OperatorModel.uxf, > GA-OperatorModel.uxf, GA-Overview.uxf, GA-Overview.uxf > > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1563: --- Attachment: GA-Model.uxf > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > Attachments: GA-Model.uxf, GA-Model.uxf, GA-OperatorModel.uxf, > GA-Overview.uxf, GA-Overview.uxf > > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1563: --- Attachment: GA-Overview.uxf > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > Attachments: GA-Model.uxf, GA-Model.uxf, GA-OperatorModel.uxf, > GA-Overview.uxf, GA-Overview.uxf > > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380592#comment-17380592 ] AVIJIT BASAK commented on MATH-1563: I have started to document the changes in UML model. The existing model has been reversed engineered from the source code. I have proposed few alterations to the existing model as well as few additions. The alterations are colored as yellow and additions as blue and removals as red. The models are separated logically in three diagrams as attached below. I have attached the diagrams here to maintain a proper reference. I have used umlet (https://www.umlet.com/ ) for drawing the diagrams. We can start the review and design discussion based on these. [^GA-Overview.uxf] [^GA-Model.uxf] [^GA-OperatorModel.uxf] > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > Attachments: GA-Model.uxf, GA-OperatorModel.uxf, GA-Overview.uxf > > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1563: --- Attachment: GA-OperatorModel.uxf > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > Attachments: GA-Model.uxf, GA-OperatorModel.uxf, GA-Overview.uxf > > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1563: --- Attachment: GA-Model.uxf > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > Attachments: GA-Model.uxf, GA-OperatorModel.uxf, GA-Overview.uxf > > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1563: --- Attachment: GA-Overview.uxf > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > Attachments: GA-Model.uxf, GA-OperatorModel.uxf, GA-Overview.uxf > > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17368101#comment-17368101 ] AVIJIT BASAK commented on MATH-1563: Could you kindly share the current repository URL where the modularization is being done. I might also need access to the repository to create feature branch and PR > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1563: --- Comment: was deleted (was: Hi Thanks for this reply. I did not notice this assuming the proposal has been rejected. Kindly allow me some time. I shall do the necessary changes and get back to you. Thanks & Regards --Avijit Basak On Sat, 29 May 2021 at 18:05, Gilles Sadowski (Jira) -- Avijit Basak ) > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17368095#comment-17368095 ] AVIJIT BASAK commented on MATH-1563: Hi Thanks for this reply. I did not notice this assuming the proposal has been rejected. Kindly allow me some time. I shall do the necessary changes and get back to you. Thanks & Regards --Avijit Basak On Sat, 29 May 2021 at 18:05, Gilles Sadowski (Jira) -- Avijit Basak > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254739#comment-17254739 ] AVIJIT BASAK commented on MATH-1563: Thanks for the update. I have subscribed to commons mailing list. Is there any other activity I need to perform for approval of this enhancement. > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253401#comment-17253401 ] AVIJIT BASAK edited comment on MATH-1563 at 12/22/20, 10:56 AM: The enhancement request was sent to "{color:#22}d...@commons.apache.org"{color} I have subscribed to "dev" ML "d...@community.apache.org". was (Author: avijit.basak): "{color:#172b4d}Did you {color}*subscribe*{color:#172b4d} to the "dev" ML?{color}" Yes, I have subscribed to "dev" ML > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253401#comment-17253401 ] AVIJIT BASAK commented on MATH-1563: "{color:#172b4d}Did you {color}*subscribe*{color:#172b4d} to the "dev" ML?{color}" Yes, I have subscribed to "dev" ML > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252436#comment-17252436 ] AVIJIT BASAK commented on MATH-1563: I have sent an email with subject "*[MATH] A Proposal for Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm*" to "*d...@commons.apache.org*" with the proposal referring this Jira. Any other activity required to pursue this? > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
[ https://issues.apache.org/jira/browse/MATH-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246307#comment-17246307 ] AVIJIT BASAK commented on MATH-1563: Thanks a lot for your reply. I would like to participate in this endeavour. I have already requested a formal approval from IBM. Let me know if there is any other formalities regarding this. > Implementation of Adaptive Probability Generation Strategy for Genetic > Algorithm > > > Key: MATH-1563 > URL: https://issues.apache.org/jira/browse/MATH-1563 > Project: Commons Math > Issue Type: Improvement >Reporter: AVIJIT BASAK >Priority: Major > > In Genetic Algorithm probability of crossover and mutation operation can be > generated in an adaptive manner. Some experiment was done related to this and > published in this article > "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. > Currently Apache's API works on constant probability strategy. I would like > to propose incorporation of rank based adaptive probability generation > strategy as described in the mentioned article. This will improve the > performance and robustness of the algorithm and would make this more suitable > for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
AVIJIT BASAK created MATH-1563: -- Summary: Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm Key: MATH-1563 URL: https://issues.apache.org/jira/browse/MATH-1563 Project: Commons Math Issue Type: Improvement Reporter: AVIJIT BASAK In Genetic Algorithm probability of crossover and mutation operation can be generated in an adaptive manner. Some experiment was done related to this and published in this article "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. Currently Apache's API works on constant probability strategy. I would like to propose incorporation of rank based adaptive probability generation strategy as described in the mentioned article. This will improve the performance and robustness of the algorithm and would make this more suitable for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)