Hello.
Le jeu. 29 sept. 2022 à 14:07, Avijit Basak <avijit.ba...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
