[jira] [Commented] (MATH-1643) Implementation of multi-threading in Genetic Algorithm and parallel GA with multiple populations.

2022-04-04 Thread AVIJIT BASAK (Jira)


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

2022-04-04 Thread AVIJIT BASAK (Jira)


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

2022-04-04 Thread AVIJIT BASAK (Jira)


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

2022-03-28 Thread AVIJIT BASAK (Jira)
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

2022-03-28 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-12-20 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-12-20 Thread AVIJIT BASAK (Jira)
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

2021-11-22 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-09-24 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-09-24 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-09-24 Thread AVIJIT BASAK (Jira)


[ 
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

2021-09-24 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-09-24 Thread AVIJIT BASAK (Jira)


[ 
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

2021-09-24 Thread AVIJIT BASAK (Jira)


[ 
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

2021-09-24 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-09-24 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-09-20 Thread AVIJIT BASAK (Jira)


[ 
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

2021-09-20 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-09-09 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-09-08 Thread AVIJIT BASAK (Jira)


[ 
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

2021-09-08 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-09-08 Thread AVIJIT BASAK (Jira)


[ 
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

2021-09-08 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-08-31 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-08-31 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-08-21 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-08-21 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-08-01 Thread AVIJIT BASAK (Jira)
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

2021-08-01 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-08-01 Thread AVIJIT BASAK (Jira)
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

2021-07-31 Thread AVIJIT BASAK (Jira)
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

2021-07-15 Thread AVIJIT BASAK (Jira)


[ 
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

2021-07-15 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-07-15 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-07-15 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-07-14 Thread AVIJIT BASAK (Jira)


[ 
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

2021-07-14 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-07-14 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-07-14 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-06-23 Thread AVIJIT BASAK (Jira)


[ 
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

2021-06-23 Thread AVIJIT BASAK (Jira)


 [ 
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

2021-06-23 Thread AVIJIT BASAK (Jira)


[ 
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

2020-12-24 Thread AVIJIT BASAK (Jira)


[ 
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

2020-12-22 Thread AVIJIT BASAK (Jira)


[ 
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

2020-12-22 Thread AVIJIT BASAK (Jira)


[ 
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

2020-12-20 Thread AVIJIT BASAK (Jira)


[ 
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

2020-12-08 Thread AVIJIT BASAK (Jira)


[ 
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

2020-12-05 Thread AVIJIT BASAK (Jira)
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)