You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Avijit Basak <av...@gmail.com> on 2022/09/29 12:07:13 UTC
Re: [MATH][GA] Issues in "commons-math4-ga2" design
Hi All
Please find my comments below:
>
>> Hi All
>>
>> The newly proposed design of "commons-math4-ga2" has two primary
>> issues which I would like to mention here.
>>
>> *1) GA logic*: The design does not conform to the basic genetic algorithm
>I understand the concern about providing the standard ("historical") GA.
>The theorem assumes the standard GA, but the example shows that
>convergence is also achieved with the variant.
-- Yes the new variant can accommodate the standard GA too.
>
>> However, the new design proposed as part of "commons-math4-ga2"
>> deviates from the basic logic. It does not distinguish the operators i.e.
>> crossover and mutation and treats them uniformly. The order of
>> operator application is also not considered.
>
>All intended as "features". ;-)
>[One being that, in the variant implementation, it is possible to apply
>any number of operators, not just one specific crossover followed by
>one mutation.]
>
>Shouldn't we be able (IIUC) to define the standard GA procedure by
>an extension of the API like the following (untested):
>---CUT---
>public class CrossoverThenMutate<G>
> extends AbstractCrossover<G> {
> private AbstractCrossover<G> c;
> private AbstractMutation<G> m;
> [...]
> private List<G> mutate(G parent,
> UniformRandomProvider rng) {
> final List<G> p = new ArrayList<G>(1);
> p.add(parent);
> return m.apply(p, rng);
> }
>}
>---CUT---
>
>AFAICT, a standard GA would thus be performed if this combined
>operator would be used as a unique operator in the GA variant.
--If we consider this approach we may need to modify our examples which
assume the standard GA.
This variant design is more appropriate for a *generalized population based
stochastic optimizer* which can accommodate other algorithms like
multi-agent gradient descent/simulated annealing, genetic algorithm(already
implemented), particle swarm optimization and large neighbourhood search
etc.
If we want to stick to this new design I would rather suggest *renaming* of
the existing interfaces so that the API can be more generic and can be used
for all other algorithms. GA should be a specific implementation for that
API.
However, we might have to think more on the multiple operator scenarios.
>
>> Along with that it executes
>> parent selection two times instead of one.
>
>That would also be taken care of with the above combined operator.
>
>> These are clear deviations from the standard approach used so far and
would
>> require a fix.
>>
>>
>> *2) Determination of mutation probability*: The newly proposed design of
>> "commons-math4-ga2" determines the probability of mutation at the
algorithm
>> level. Same approach was used in math 3.x implementation. However, this
>> approach considers the probability of mutation at the chromosome level
not
>> at the allele/gene level. I have found a considerable difference in the
>> quality of optimization between two cases. Determining the mutation
>> probability at the gene/allele level has given a
>> considerably better result.
>
>A runnable test case (that creates a comparison) would be quite useful
>to illustrate the feature.
>
>> Usage of mutation probability at the chromosome
>> level would only ensure mutation of a single allele irrespective of
>> probability
>
>?
>In the basic implementation for the "binary" genotype (in class
>"o.a.c.m.ga2.gene.binary.Mutation"), there is a loop over all the
>alleles.
>
>> or chromosome size. There is no such limitation in case the
>> mutation probability is decided at the allele level and can be easily
>> controlled by users for fine tuning. This has helped to improve the
>> optimization quality thus providing better results. This is only related
to
>> mutation not crossover. But we can maintain an uniform approach and let
the
>> operator decide on the probability.
>
>I don't understand.
>Please refer to the class mentioned above and describe the required
>modifications.
-- E.g. assume the user is having a chromosome population of size 10 and
chromosome length is 10.
mutation probability no of alleles modified per chromosome no of
alleles modified in population
.2 2
20
.1 1
10
.05 --
5
.02 --
2
.2 2
20
This way users can have more freedom over allele variation in the entire
population.
Thanks & Regards
--Avijit Basak
On Tue, 16 Aug 2022 at 05:55, Gilles Sadowski <gi...@gmail.com> wrote:
> Hello.
>
> Le lun. 15 août 2022 à 17:23, Avijit Basak <av...@gmail.com> a
> écrit :
> >
> > Hi All
> >
> > The newly proposed design of "commons-math4-ga2" has two primary
> > issues which I would like to mention here.
> >
> > *1) GA logic*: The design does not conform to the basic genetic algorithm
> > concepts proposed by John Holland. The pseudocode representing the
> original
> > algorithm logic is provided below:
> > --CUT--
> > while(!converged(population)) {
> > Population newPopulation = new Population();
> > for(int i = 0; i < size(population)/2; i++) {
> > // select parents
> > ChromosomePair parents = select(population);
> > // do crossover
> > ChromosomePair offsprings = crossover(parents);
> > //do mutation
> > Chromosome chromosome1 = mutate(offsprings[0]);
> > Chromosome chromosome2 = mutate(offsprings[1]);
> > // Add mutated chromosomes to population
> > newPopulation.add(chromosome1);
> > newPopulation.add(chromosome2);
> > }
> > }
> > --CUT--
> >
> > However, the implementation proposed in "commons-math4-ga2" can be
> > represented by the pseudocode provided below.
> > --CUT--
> > while(!converged(population)) {
> > List<GeneticOperator> operators;
> > Population newPopulation = new Population();
> > for(int i = 0; i < size(population)/2; i++) {
> > for(GeneticOperator operator : operators) {
> > // select parents
> > ChromosomePair parents = select(population);
> > // apply operator
> > ChromosomePair offsprings = operator.apply(parents);
> > // Add chromosomes to population
> > newPopulation.add( offsprings[0] );
> > newPopulation.add( offsprings[1] );
> > }
> > }
> > }
> > --CUT--
> > N.B. The use of probability and elitism has been avoided to keep the
> logic
> > simplified.
> >
> > The first one has been used by the engineering community for decades
> > and is proved to be effective. There is also a mathematical model based
> on
> > schema theorem(
> >
> https://en.wikipedia.org/wiki/Holland%27s_schema_theorem#:~:text=The%20Schema%20Theorem%20says%20that,the%20power%20of%20genetic%20algorithms
> .)
> > to support the effectiveness of the algorithm. Same has been followed by
> me
> > for implementation of "commons-math4-ga" module.
>
> I understand the concern about providing the standard ("historical") GA.
> The theorem assumes the standard GA, but the example shows that
> convergence is also achieved with the variant.
>
> > However, the new design proposed as part of "commons-math4-ga2"
> > deviates from the basic logic. It does not distinguish the operators i.e.
> > crossover and mutation and treats them uniformly. The order of
> > operator application is also not considered.
>
> All intended as "features". ;-)
> [One being that, in the variant implementation, it is possible to apply
> any number of operators, not just one specific crossover followed by
> one mutation.]
>
> Shouldn't we be able (IIUC) to define the standard GA procedure by
> an extension of the API like the following (untested):
> ---CUT---
> public class CrossoverThenMutate<G>
> extends AbstractCrossover<G> {
> private AbstractCrossover<G> c;
> private AbstractMutation<G> m;
>
> public CrossoverThenMutate(AbstractCrossover<G> c,
> AbstractMutation<G> m) {
> this.c = c;
> this.m = m;
> }
>
> @Override
> protected List<G> apply(G parent1,
> G parent2,
> UniformRandomProvider rng) {
> // Crossover.
> final List<G> cR = c.apply(parent1, parent2, rng);
>
> // Mutate.
> final List<G> r = new ArrayList<G>(2);
> r.add(mutate(cR.get(0), rng));
> r.add(mutate(cR.get(1), rng));
>
> return r;
> }
>
> private List<G> mutate(G parent,
> UniformRandomProvider rng) {
> final List<G> p = new ArrayList<G>(1);
> p.add(parent);
> return m.apply(p, rng);
> }
> }
> ---CUT---
>
> AFAICT, a standard GA would thus be performed if this combined
> operator would be used as a unique operator in the GA variant.
>
> > Along with that it executes
> > parent selection two times instead of one.
>
> That would also be taken care of with the above combined operator.
>
> > These are clear deviations from the standard approach used so far and
> would
> > require a fix.
> >
> >
> > *2) Determination of mutation probability*: The newly proposed design of
> > "commons-math4-ga2" determines the probability of mutation at the
> algorithm
> > level. Same approach was used in math 3.x implementation. However, this
> > approach considers the probability of mutation at the chromosome level
> not
> > at the allele/gene level. I have found a considerable difference in the
> > quality of optimization between two cases. Determining the mutation
> > probability at the gene/allele level has given a
> > considerably better result.
>
> A runnable test case (that creates a comparison) would be quite useful
> to illustrate the feature.
>
> > Usage of mutation probability at the chromosome
> > level would only ensure mutation of a single allele irrespective of
> > probability
>
> ?
> In the basic implementation for the "binary" genotype (in class
> "o.a.c.m.ga2.gene.binary.Mutation"), there is a loop over all the
> alleles.
>
> > or chromosome size. There is no such limitation in case the
> > mutation probability is decided at the allele level and can be easily
> > controlled by users for fine tuning. This has helped to improve the
> > optimization quality thus providing better results. This is only related
> to
> > mutation not crossover. But we can maintain an uniform approach and let
> the
> > operator decide on the probability.
>
> I don't understand.
> Please refer to the class mentioned above and describe the required
> modifications.
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Avijit Basak
Re: [MATH][GA] Issues in "commons-math4-ga2" design
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le sam. 15 oct. 2022 à 16:39, Avijit Basak <av...@gmail.com> a écrit :
>
> Hi All
>
> Please see my comments below. Kindly share further thoughts.
>
> > [...]
> >I'm not sure what you mean: The examples just run a GA-like algorithm,
> >but (AFAICT) do not compare the output to some expected outcome.
> -- I have some code changes in the "examples-ga-math-functions" module to
> compare results of two modules "commons-math4-ga" and "commons-math4-ga2".
> A graphical approach using JFreeChart has been adopted for the same. A new
> value "COMPARE" has been introduced for the "--api" input argument to
> initiate the comparison.
I think that I already raised the issue of "fancy" output not being the most
appropriate choice for developing things here; GUI especially tend to become
outdated fast, and we are left with cruft code to update to <whatever> is the
new trend (a few months ago, I had to remove GUI examples for the clustering
functionality).
It's great if the component contains tools that help in debugging, but those
should be text-based (see e.g. the benchmarks and stress tests infrastructure
in "Commons RNG").
Otherwise, debugging is performed on the developers' own computers and
information is collected in JIRA (where you can post pictures which you have
created locally).
Please do so (you are welcome to create a dedicated report) so that we can
make progress, on this particular point, from concrete elements.
> The "commons-math4-ga" module consistently provided better results than
> "commons-math4-ga2".
> The code is kept in my repo
> https://github.com/avijit-basak/commons-math/tree/feature/MATH-1563_comparison
> .
> I did not raise a PR till now. This is only kept in my repo for comparison.
> Could you please check if the feature__MATH-1563__genetic_algorithm branch
> does contain changes from master of apache repo.
I'm not sure what you mean here.
I tried
$ git rebase master
within the
feature__MATH-1563__genetic_algorithm
branch.
But I after I fix the conflicting files, and issue
$ git rebase --continue
I'm getting more and more conflicts in Java files in "common-math-ga"
module; since those are supposed to only exist in the "feature" branch,
I don't know what's going on.
A local problem on my machine?
> [...]
>
> >
> >[1] My main argument for the "GA variant" is that it is much simpler, for
> > what seems equivalent functionality (bugs, or misinterpretation of
> > expected behaviour, notwithstanding): Current counts of lines of
> > code is 696 vs 2038.
> -- The variant only contains options for binary genotype but the
> "commons-math4-ga" module provides options for other genotypes too. So, we
> may not compare the lines of code.
Yes we can. Even removing the code in package "chromosome", there
are quite many more lines in module "commons-math-ga".
Also, there is a lot of code dedicated to managing the representation of
"binary" chromosomes whereas, in "commons-math-ga2", I've used the
JDK "BitSet".
> However, considering the optimization
> result and options of genotypes
I noted from the outset (cf. ML archive) that I didn't implement the
other genotypes, since my point was only to provide a "proof of
concept" about how to fix the (implementation) issues which I had
with the code in "commons-math-ga".
I've always known that functionality is lacking in "commons-math-ga2",
but I was expecting that you'd fill those gaps (genotypes and unit tests)
once we'd agree that your initial implementation was unnecessarily
complex (one measure of it being the line count).
> I would still vote for "commons-math4-ga"
> instead of its new variant.
The question does not come in these terms (i.e. one or the other,
in the state that they are now). Rather, we'll have to converge to a
piece of code that is both correct (i.e. provide the results which you
expect) and maintainable (i.e. free of the "commons-math-ga" issues
which I've fixed in "commons-math-ga2").
Hopefully your analysis on JIRA will uncover the bug(s) that entail the
problems which you are observing. They can then be fixed and we'll
get the "best of both worlds".
Regards,
Gilles
> > > > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH][GA] Issues in "commons-math4-ga2" design
Posted by Avijit Basak <av...@gmail.com>.
Hi All
Please see my comments below. Kindly share further thoughts.
> [...]
>I'm not sure what you mean: The examples just run a GA-like algorithm,
>but (AFAICT) do not compare the output to some expected outcome.
-- I have some code changes in the "examples-ga-math-functions" module to
compare results of two modules "commons-math4-ga" and "commons-math4-ga2".
A graphical approach using JFreeChart has been adopted for the same. A new
value "COMPARE" has been introduced for the "--api" input argument to
initiate the comparison.
The "commons-math4-ga" module consistently provided better results than
"commons-math4-ga2".
The code is kept in my repo
https://github.com/avijit-basak/commons-math/tree/feature/MATH-1563_comparison
.
I did not raise a PR till now. This is only kept in my repo for comparison.
Could you please check if the feature__MATH-1563__genetic_algorithm branch
does contain changes from master of apache repo.
>> This variant design is more appropriate for a *generalized population
based
>> stochastic optimizer* which can accommodate other algorithms like
>> multi-agent gradient descent/simulated annealing, genetic
algorithm(already
>> implemented), particle swarm optimization and large neighbourhood search
>> etc.
>> If we want to stick to this new design I would rather suggest *renaming*
of
>> the existing interfaces so that the API can be more generic and can be
used
>> for all other algorithms. GA should be a specific implementation for that
>> API.
>> However, we might have to think more on the multiple operator scenarios.
>
>An interesting suggestion. If the generalized API can be achieved
>easily, I'm all for it.
>However, I wonder how useful it will be, as every actual optimizer
>implementation may
> * require substantial adaptations to fit the common API
> * need extensions to provide access to specific features (which
> would decrease the usefulness of the common API for users).
[...]
-- We can avoid that for now as that will be a bigger task.
>
>[1] My main argument for the "GA variant" is that it is much simpler, for
> what seems equivalent functionality (bugs, or misinterpretation of
> expected behaviour, notwithstanding): Current counts of lines of
> code is 696 vs 2038.
-- The variant only contains options for binary genotype but the
"commons-math4-ga" module provides options for other genotypes too. So, we
may not compare the lines of code. However, considering the optimization
result and options of genotypes I would still vote for "commons-math4-ga"
instead of its new variant.
Thanks & Regards
--Avijit Basak
On Thu, 29 Sept 2022 at 22:42, Gilles Sadowski <gi...@gmail.com> wrote:
> Hello.
>
> Le jeu. 29 sept. 2022 à 14:07, Avijit Basak <av...@gmail.com> a
> écrit :
> >
> > Hi All
> >
> > Please find my comments below:
> >
> > >
> > >> Hi All
> > >>
> > >> The newly proposed design of "commons-math4-ga2" has two
> primary
> > >> issues which I would like to mention here.
> > >>
> > >> *1) GA logic*: The design does not conform to the basic genetic
> algorithm
> > >I understand the concern about providing the standard ("historical") GA.
> > >The theorem assumes the standard GA, but the example shows that
> > >convergence is also achieved with the variant.
> >
> > -- Yes the new variant can accommodate the standard GA too.
> >
> > >
> > >> However, the new design proposed as part of "commons-math4-ga2"
> > >> deviates from the basic logic. It does not distinguish the operators
> i.e.
> > >> crossover and mutation and treats them uniformly. The order of
> > >> operator application is also not considered.
> > >
> > >All intended as "features". ;-)
> > >[One being that, in the variant implementation, it is possible to apply
> > >any number of operators, not just one specific crossover followed by
> > >one mutation.]
> > >
> > >Shouldn't we be able (IIUC) to define the standard GA procedure by
> > >an extension of the API like the following (untested):
> > >---CUT---
> > >public class CrossoverThenMutate<G>
> > > extends AbstractCrossover<G> {
> > > private AbstractCrossover<G> c;
> > > private AbstractMutation<G> m;
> > > [...]
> > > private List<G> mutate(G parent,
> > > UniformRandomProvider rng) {
> > > final List<G> p = new ArrayList<G>(1);
> > > p.add(parent);
> > > return m.apply(p, rng);
> > > }
> > >}
> > >---CUT---
> > >
> > >AFAICT, a standard GA would thus be performed if this combined
> > >operator would be used as a unique operator in the GA variant.
> >
> > --If we consider this approach we may need to modify our examples which
> > assume the standard GA.
>
> I'm not sure what you mean: The examples just run a GA-like algorithm,
> but (AFAICT) do not compare the output to some expected outcome.
>
> > This variant design is more appropriate for a *generalized population
> based
> > stochastic optimizer* which can accommodate other algorithms like
> > multi-agent gradient descent/simulated annealing, genetic
> algorithm(already
> > implemented), particle swarm optimization and large neighbourhood search
> > etc.
> > If we want to stick to this new design I would rather suggest *renaming*
> of
> > the existing interfaces so that the API can be more generic and can be
> used
> > for all other algorithms. GA should be a specific implementation for that
> > API.
> > However, we might have to think more on the multiple operator scenarios.
>
> An interesting suggestion. If the generalized API can be achieved
> easily, I'm all for it.
> However, I wonder how useful it will be, as every actual optimizer
> implementation may
> * require substantial adaptations to fit the common API
> * need extensions to provide access to specific features (which
> would decrease the usefulness of the common API for users).
> I'm mentioning this because we tried to design such a common API
> for the optimizers implemented in package "o.a.c.m.optim", with
> eventual shortcomings.
> Another counter-argument is that the "abstract" optimization recipe
> that would be defined in terms of the high-level API is generally
> fairly simple (compared to an algorithm concrete implementation);
> we'd just save a few lines of code that can otherwise be easily
> provided in the documentation.
>
> Anyways, let us know whether you want to explore this further
> (through providing actual code).
> I think (?) that it could be done in a separate (maven) module
> which the GA module would depend on.
> [IIUC, another "population-based" algorithm to depend on this
> API would be the "CMAESOptimizer" that currently is adapted
> to the "optim" API which I mentioned above...]
>
> > >
> > >> Along with that it executes
> > >> parent selection two times instead of one.
> > >
> > >That would also be taken care of with the above combined operator.
> > >
> > >> These are clear deviations from the standard approach used so far and
> > would
> > >> require a fix.
> > >>
> > >>
> > >> *2) Determination of mutation probability*: The newly proposed design
> of
> > >> "commons-math4-ga2" determines the probability of mutation at the
> > algorithm
> > >> level. Same approach was used in math 3.x implementation. However,
> this
> > >> approach considers the probability of mutation at the chromosome level
> > not
> > >> at the allele/gene level. I have found a considerable difference in
> the
> > >> quality of optimization between two cases. Determining the mutation
> > >> probability at the gene/allele level has given a
> > >> considerably better result.
> > >
> > >A runnable test case (that creates a comparison) would be quite useful
> > >to illustrate the feature.
> > >
> > >> Usage of mutation probability at the chromosome
> > >> level would only ensure mutation of a single allele irrespective of
> > >> probability
> > >
> > >?
> > >In the basic implementation for the "binary" genotype (in class
> > >"o.a.c.m.ga2.gene.binary.Mutation"), there is a loop over all the
> > >alleles.
> > >
> > >> or chromosome size. There is no such limitation in case the
> > >> mutation probability is decided at the allele level and can be easily
> > >> controlled by users for fine tuning. This has helped to improve the
> > >> optimization quality thus providing better results. This is only
> related
> > to
> > >> mutation not crossover. But we can maintain an uniform approach and
> let
> > the
> > >> operator decide on the probability.
> > >
> > >I don't understand.
> > >Please refer to the class mentioned above and describe the required
> > >modifications.
> > -- E.g. assume the user is having a chromosome population of size 10 and
> > chromosome length is 10.
> > mutation probability no of alleles modified per chromosome no
> of
> > alleles modified in population
> > .2 2
> > 20
> > .1 1
> > 10
> > .05 --
> > 5
> > .02 --
> > 2
> > .2 2
> > 20
> >
> > This way users can have more freedom over allele variation in the entire
> > population.
>
> We really need code (and unit tests to assert the expected
> functionality)...
>
> I hope that a "beta" release of CM can occur as soon as the components
> which it depends on have had their own ("beta" or not).
> So the question is: What to release as the GA module?
> More to the point, what exactly do we need to change, or add, in the "GA
> variant" code proposal in order to make it suitable for general usage?[1]
> [I'm referring here to actual functionality (operators, representations,
> ...),
> not to the hypothetical framework possibly shared by other algorithms.]
>
> Regards,
> Gilles
>
> [1] My main argument for the "GA variant" is that it is much simpler, for
> what seems equivalent functionality (bugs, or misinterpretation of
> expected behaviour, notwithstanding): Current counts of lines of
> code is 696 vs 2038.
>
> > > [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [MATH][GA] Issues in "commons-math4-ga2" design
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le jeu. 29 sept. 2022 à 14:07, Avijit Basak <av...@gmail.com> a écrit :
>
> Hi All
>
> Please find my comments below:
>
> >
> >> Hi All
> >>
> >> The newly proposed design of "commons-math4-ga2" has two primary
> >> issues which I would like to mention here.
> >>
> >> *1) GA logic*: The design does not conform to the basic genetic algorithm
> >I understand the concern about providing the standard ("historical") GA.
> >The theorem assumes the standard GA, but the example shows that
> >convergence is also achieved with the variant.
>
> -- Yes the new variant can accommodate the standard GA too.
>
> >
> >> However, the new design proposed as part of "commons-math4-ga2"
> >> deviates from the basic logic. It does not distinguish the operators i.e.
> >> crossover and mutation and treats them uniformly. The order of
> >> operator application is also not considered.
> >
> >All intended as "features". ;-)
> >[One being that, in the variant implementation, it is possible to apply
> >any number of operators, not just one specific crossover followed by
> >one mutation.]
> >
> >Shouldn't we be able (IIUC) to define the standard GA procedure by
> >an extension of the API like the following (untested):
> >---CUT---
> >public class CrossoverThenMutate<G>
> > extends AbstractCrossover<G> {
> > private AbstractCrossover<G> c;
> > private AbstractMutation<G> m;
> > [...]
> > private List<G> mutate(G parent,
> > UniformRandomProvider rng) {
> > final List<G> p = new ArrayList<G>(1);
> > p.add(parent);
> > return m.apply(p, rng);
> > }
> >}
> >---CUT---
> >
> >AFAICT, a standard GA would thus be performed if this combined
> >operator would be used as a unique operator in the GA variant.
>
> --If we consider this approach we may need to modify our examples which
> assume the standard GA.
I'm not sure what you mean: The examples just run a GA-like algorithm,
but (AFAICT) do not compare the output to some expected outcome.
> This variant design is more appropriate for a *generalized population based
> stochastic optimizer* which can accommodate other algorithms like
> multi-agent gradient descent/simulated annealing, genetic algorithm(already
> implemented), particle swarm optimization and large neighbourhood search
> etc.
> If we want to stick to this new design I would rather suggest *renaming* of
> the existing interfaces so that the API can be more generic and can be used
> for all other algorithms. GA should be a specific implementation for that
> API.
> However, we might have to think more on the multiple operator scenarios.
An interesting suggestion. If the generalized API can be achieved
easily, I'm all for it.
However, I wonder how useful it will be, as every actual optimizer
implementation may
* require substantial adaptations to fit the common API
* need extensions to provide access to specific features (which
would decrease the usefulness of the common API for users).
I'm mentioning this because we tried to design such a common API
for the optimizers implemented in package "o.a.c.m.optim", with
eventual shortcomings.
Another counter-argument is that the "abstract" optimization recipe
that would be defined in terms of the high-level API is generally
fairly simple (compared to an algorithm concrete implementation);
we'd just save a few lines of code that can otherwise be easily
provided in the documentation.
Anyways, let us know whether you want to explore this further
(through providing actual code).
I think (?) that it could be done in a separate (maven) module
which the GA module would depend on.
[IIUC, another "population-based" algorithm to depend on this
API would be the "CMAESOptimizer" that currently is adapted
to the "optim" API which I mentioned above...]
> >
> >> Along with that it executes
> >> parent selection two times instead of one.
> >
> >That would also be taken care of with the above combined operator.
> >
> >> These are clear deviations from the standard approach used so far and
> would
> >> require a fix.
> >>
> >>
> >> *2) Determination of mutation probability*: The newly proposed design of
> >> "commons-math4-ga2" determines the probability of mutation at the
> algorithm
> >> level. Same approach was used in math 3.x implementation. However, this
> >> approach considers the probability of mutation at the chromosome level
> not
> >> at the allele/gene level. I have found a considerable difference in the
> >> quality of optimization between two cases. Determining the mutation
> >> probability at the gene/allele level has given a
> >> considerably better result.
> >
> >A runnable test case (that creates a comparison) would be quite useful
> >to illustrate the feature.
> >
> >> Usage of mutation probability at the chromosome
> >> level would only ensure mutation of a single allele irrespective of
> >> probability
> >
> >?
> >In the basic implementation for the "binary" genotype (in class
> >"o.a.c.m.ga2.gene.binary.Mutation"), there is a loop over all the
> >alleles.
> >
> >> or chromosome size. There is no such limitation in case the
> >> mutation probability is decided at the allele level and can be easily
> >> controlled by users for fine tuning. This has helped to improve the
> >> optimization quality thus providing better results. This is only related
> to
> >> mutation not crossover. But we can maintain an uniform approach and let
> the
> >> operator decide on the probability.
> >
> >I don't understand.
> >Please refer to the class mentioned above and describe the required
> >modifications.
> -- E.g. assume the user is having a chromosome population of size 10 and
> chromosome length is 10.
> mutation probability no of alleles modified per chromosome no of
> alleles modified in population
> .2 2
> 20
> .1 1
> 10
> .05 --
> 5
> .02 --
> 2
> .2 2
> 20
>
> This way users can have more freedom over allele variation in the entire
> population.
We really need code (and unit tests to assert the expected functionality)...
I hope that a "beta" release of CM can occur as soon as the components
which it depends on have had their own ("beta" or not).
So the question is: What to release as the GA module?
More to the point, what exactly do we need to change, or add, in the "GA
variant" code proposal in order to make it suitable for general usage?[1]
[I'm referring here to actual functionality (operators, representations, ...),
not to the hypothetical framework possibly shared by other algorithms.]
Regards,
Gilles
[1] My main argument for the "GA variant" is that it is much simpler, for
what seems equivalent functionality (bugs, or misinterpretation of
expected behaviour, notwithstanding): Current counts of lines of
code is 696 vs 2038.
> > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org