Re: [MATH][GENETICS][PR#199] Design Decision of Chromosome hierarchy
Hi All I have uploaded the image(*chromosome hierarchy.png*) in JIRA. Here is the link. Let me know if anyone faces any issues. https://issues.apache.org/jira/projects/MATH/issues/MATH-1563?filter=allopenissues Thanks & Regards --Avijit Basak On Mon, 22 Nov 2021 at 19:39, Gilles Sadowski wrote: > Hello. > > Le lun. 22 nov. 2021 à 13:47, Avijit Basak a > écrit : > > > > Hi All > > > > We need to make a decision on the chromosome hierarchy, proposed > for commons-math-ga module. > > Currently the hierarchy is designed as shown in the diagram below. > > Image has probably been stripped from your original message. > Please upload it to JIRA and post a link here. > > Thanks, > Gilles > > > > > > > Brief description: > > 1) The chromosome hierarchy is based on it's internal representation of > Genotype. > > 2) The phenotype of chromosomes is kept as a Generic parameter . > > 3) Decoder is introduced to convert Genotype to Phenotype. > > 4) FitnessFunction is introduced to calculate Fitness of chromosomes. > > 5) AbstractChromosome represents the chromosome abstraction for all > genotypes. > > 6) AbstractListChromosome has been introduced to represent the > abstraction for List based Genotype. > > 7) Any chromosome representing list based genotypes should extend > AbstractListBasedChromosome. > > 8) All other chromosomes should extend the AbstractChromosome class. > > 9) BinaryChromosome(not committed) is introduced to represent binary > genotypes and extends AbstractChromosome. > > > > Pros: > > 1) This hierarchy maintains a separation of Genotype and Phenotype. > > 2) Chromosome class with the same genotype can represent different > phenotypes with different implementations of Decoders. > > 3) Users will be able to use primitive types for higher dimensions by > extending the AbstractChromosome class. > > 4) Unlike the legacy model all concrete chromosomes are reusable with > proper implementation of FitnessFunction and Decoder. > > 5) Any custom list based genotypes can be implemented by extending > AbstractListChromosome class. > > 6) Internal genotype representations have been exposed which enabled the > reuse of crossover and mutation operators. > > > > I would like to request everyone to review the design and reply > in case of any concerns. > > > > > > Thanks & Regards > > -- Avijit Basak > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Avijit Basak
Re: [MATH][GENETICS][PR-199] Decision on the use of Logging functionality
I’d be +1 for Log4j2 as the API particularly due to the more active development community and licensing. SLF4J is mostly reliant on the heroic efforts of its sole maintainer which is a bit of an anti-pattern at Apache. If there’s a desire to support the Java module system, the only versions of SLF4J that properly support them are still in alpha or beta releases right now. > On Nov 22, 2021, at 08:05, Gilles Sadowski wrote: > > Hello. > > Le lun. 22 nov. 2021 à 13:50, Avijit Basak a écrit : >> >> Hi All >> >> We need to make a decision on usage of a logging framework. The >> previous release does not have any implementation of a logging framework. >> However, in the current implementation a slf4j logger has been introduced. >> Please share if anyone has any concerns related to this. > > +1 for using > * the (de-facto standard) SFL4J _interfaces_ [1] in the "src" part of the > GA module, > * Log4j2 [2] implementations in the "test" part of the GA module (and in > the example applications). > > Best, > Gilles > > [1] http://www.slf4j.org/ > [2] https://logging.apache.org/log4j/2.x/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH][GENETICS][PR#199] Design Decision of Chromosome hierarchy
Hello. Le lun. 22 nov. 2021 à 13:47, Avijit Basak a écrit : > > Hi All > > We need to make a decision on the chromosome hierarchy, proposed for > commons-math-ga module. > Currently the hierarchy is designed as shown in the diagram below. Image has probably been stripped from your original message. Please upload it to JIRA and post a link here. Thanks, Gilles > > > Brief description: > 1) The chromosome hierarchy is based on it's internal representation of > Genotype. > 2) The phenotype of chromosomes is kept as a Generic parameter . > 3) Decoder is introduced to convert Genotype to Phenotype. > 4) FitnessFunction is introduced to calculate Fitness of chromosomes. > 5) AbstractChromosome represents the chromosome abstraction for all genotypes. > 6) AbstractListChromosome has been introduced to represent the abstraction > for List based Genotype. > 7) Any chromosome representing list based genotypes should extend > AbstractListBasedChromosome. > 8) All other chromosomes should extend the AbstractChromosome class. > 9) BinaryChromosome(not committed) is introduced to represent binary > genotypes and extends AbstractChromosome. > > Pros: > 1) This hierarchy maintains a separation of Genotype and Phenotype. > 2) Chromosome class with the same genotype can represent different phenotypes > with different implementations of Decoders. > 3) Users will be able to use primitive types for higher dimensions by > extending the AbstractChromosome class. > 4) Unlike the legacy model all concrete chromosomes are reusable with proper > implementation of FitnessFunction and Decoder. > 5) Any custom list based genotypes can be implemented by extending > AbstractListChromosome class. > 6) Internal genotype representations have been exposed which enabled the > reuse of crossover and mutation operators. > > I would like to request everyone to review the design and reply in > case of any concerns. > > > Thanks & Regards > -- Avijit Basak - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH][GENETICS][PR-199] Decision on the use of Logging functionality
Hello. Le lun. 22 nov. 2021 à 13:50, Avijit Basak a écrit : > > Hi All > >We need to make a decision on usage of a logging framework. The > previous release does not have any implementation of a logging framework. > However, in the current implementation a slf4j logger has been introduced. > Please share if anyone has any concerns related to this. +1 for using * the (de-facto standard) SFL4J _interfaces_ [1] in the "src" part of the GA module, * Log4j2 [2] implementations in the "test" part of the GA module (and in the example applications). Best, Gilles [1] http://www.slf4j.org/ [2] https://logging.apache.org/log4j/2.x/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH][GENETICS][PR-199] Decision on use and customization of RNG functionality for randomization
Hello.
Le lun. 22 nov. 2021 à 13:49, Avijit Basak a écrit :
>
> Hi All
>
> I would like to request everyone to share their opinion regarding
> use and customization of RNG functionality in the Genetic Algorithm
> library.
> In current design RNG functionality has been used internally by the
> RandomProviderManager class. This class encapsulates a predefined instance
> of RandomSource and utilizes the same for all random number generation
> requirements. This makes the API cleaner and easy to use for users.
> However, during the review an alternate thought has been proposed
> related to customization of RandomSource by users. According to the new
> proposal the users will be able to provide a RandomSource instance of their
> choice to the crossover and mutation operators and other places like
> ChromosomeRepresentationUtils. The drawback of this customization could be
> increased complexity of the API.
Please provide an usage example of both (showing that the alternative
would actually increase the API complexity).
Thanks,
Gilles
> We need to decide here whether we really need this kind of
> customization by users and if yes the method of doing so. Here two options
> have been proposed.
> *Option1:*
> ---CUT---
> public interface MutationPolicy {
> Chromosome mutate(Chromosome original, double mutationRate);
>
> interface Factory {
> /**
> * Creates an instance with a dedicated source of randomness.
> *
> * @param rng RNG algorithm.
> * @param seed Seed.
> * @return an instance that must not be shared among
> threads.
> */
> MutationPolicy create(RandomSource rng, Object seed);
>
> default MutationPolicy create(RandomSource rng) {
> return create(rng, null);
> }
> default MutationPolicy create() {
> return create(RandomSource.SPLIT_MIX_64);
> }
> }
> }
> ---CUT---
>
> *Option 2:*
> Use of an optional constructor argument for all crossover and mutation
> operators. Users will be providing a RandomSource instance of their choice
> or use the default one configured while instantiating the operators.
>
> Thanks & Regards
> -- Avijit Basak
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH][GENETICS][PR#199] Decision on retention of ASCII Art in Javadoc section
Hello. Le lun. 22 nov. 2021 à 13:48, Avijit Basak a écrit : > > Hi All > > I would like to inform everyone that there is some ASCII art in the > javadoc section in some classes like OnePointCrossover etc. This is taken > unaltered from the previous release of math library. We need to decide > whether we should keep them in the next release or remove them. I would > like to request everyone to share their opinion. As I indicated previously, the top preference has, for years, been to use links to standard references (either Wikipedia[1] or Mathworld) when they exist. These days, nobody will bother making sense of ASCII art whenever nice graphics and thorough explanations are one click away. Gilles [1] https://en.wikipedia.org/wiki/Crossover_(genetic_algorithm) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[MATH][GENETICS][PR-199] Decision on the use of Logging functionality
Hi All We need to make a decision on usage of a logging framework. The previous release does not have any implementation of a logging framework. However, in the current implementation a slf4j logger has been introduced. Please share if anyone has any concerns related to this. Thanks & Regards -- Avijit Basak
[MATH][GENETICS][PR-199] Decision on use and customization of RNG functionality for randomization
Hi All
I would like to request everyone to share their opinion regarding
use and customization of RNG functionality in the Genetic Algorithm
library.
In current design RNG functionality has been used internally by the
RandomProviderManager class. This class encapsulates a predefined instance
of RandomSource and utilizes the same for all random number generation
requirements. This makes the API cleaner and easy to use for users.
However, during the review an alternate thought has been proposed
related to customization of RandomSource by users. According to the new
proposal the users will be able to provide a RandomSource instance of their
choice to the crossover and mutation operators and other places like
ChromosomeRepresentationUtils. The drawback of this customization could be
increased complexity of the API.
We need to decide here whether we really need this kind of
customization by users and if yes the method of doing so. Here two options
have been proposed.
*Option1:*
---CUT---
public interface MutationPolicy {
Chromosome mutate(Chromosome original, double mutationRate);
interface Factory {
/**
* Creates an instance with a dedicated source of randomness.
*
* @param rng RNG algorithm.
* @param seed Seed.
* @return an instance that must not be shared among
threads.
*/
MutationPolicy create(RandomSource rng, Object seed);
default MutationPolicy create(RandomSource rng) {
return create(rng, null);
}
default MutationPolicy create() {
return create(RandomSource.SPLIT_MIX_64);
}
}
}
---CUT---
*Option 2:*
Use of an optional constructor argument for all crossover and mutation
operators. Users will be providing a RandomSource instance of their choice
or use the default one configured while instantiating the operators.
Thanks & Regards
-- Avijit Basak
[MATH][GENETICS][PR#199] Decision on retention of ASCII Art in Javadoc section
Hi All I would like to inform everyone that there is some ASCII art in the javadoc section in some classes like OnePointCrossover etc. This is taken unaltered from the previous release of math library. We need to decide whether we should keep them in the next release or remove them. I would like to request everyone to share their opinion. Thanks & Regards -- Avijit Basak
[MATH][GENETICS][PR#199] Design Decision of Chromosome hierarchy
Hi All We need to make a decision on the chromosome hierarchy, proposed for *commons-math-ga* module. Currently the hierarchy is designed as shown in the diagram below. [image: image.png] *Brief description:* 1) The chromosome hierarchy is based on it's internal representation of Genotype. 2) The phenotype of chromosomes is kept as a Generic parameter <*P>*. 3) Decoder is introduced to convert Genotype to Phenotype. 4) FitnessFunction is introduced to calculate Fitness of chromosomes. 5) AbstractChromosome represents the chromosome abstraction for all genotypes. 6) AbstractListChromosome has been introduced to represent the abstraction for List based Genotype. 7) Any chromosome representing list based genotypes should extend AbstractListBasedChromosome. 8) All other chromosomes should extend the AbstractChromosome class. 9) BinaryChromosome(not committed) is introduced to represent binary genotypes and extends AbstractChromosome. *Pros:* 1) This hierarchy maintains a separation of Genotype and Phenotype. 2) Chromosome class with the same genotype can represent different phenotypes with different implementations of Decoders. 3) Users will be able to use primitive types for higher dimensions by extending the AbstractChromosome class. 4) Unlike the legacy model all concrete chromosomes are reusable with proper implementation of FitnessFunction and Decoder. 5) Any custom list based genotypes can be implemented by extending AbstractListChromosome class. 6) Internal genotype representations have been exposed which enabled the reuse of crossover and mutation operators. I would like to request everyone to review the design and reply in case of any concerns. Thanks & Regards -- Avijit Basak
