Hi All
I have started to work in genetic module. I want to push the new
module as part of a new feature branch "*feature/MATH-1563*". Changes
include mostly the existing code and modfication due to the new Exception
class. I have encountered the following error which indicates my Github Id "
*avijitbasak*" is not permitted to check-in code in the repository. Could
anyone kindly grant me access to the repository. Let me know if I need to
do anything else regarding this.
git.exe push --progress "origin" feature/MATH-1563
remote: Permission to apache/commons-math.git denied to avijitbasak.
fatal: unable to access '*https://github.com/apache/commons-math.git/
<https://github.com/apache/commons-math.git/>*': The requested URL returned
error: *403*
Thanks & Regards
--Avijit Basak
On Sun, 8 Aug 2021 at 10:49, Avijit Basak <avijit.ba...@gmail.com> wrote:
> Hi
>
> I have created two new subtasks for Jira *MATH-1563* to explain
> the requirement of changes and a new JIRA MATH-1618
> <https://issues.apache.org/jira/browse/MATH-1618>.
> Let me know if that helps. We can continue the discussion here
> in case of any queries.
>
> Thanks & Regards
> --Avijit Basak
>
> On Wed, 28 Jul 2021 at 23:22, Gilles Sadowski <gillese...@gmail.com>
> wrote:
>
>> Hello.
>>
>> Le mer. 28 juil. 2021 à 10:23, Avijit Basak <avijit.ba...@gmail.com> a
>> écrit :
>> >
>> > Hi
>> >
>> > I shall try to describe my proposed changes with proper context
>> in
>> > my next communication. Regarding the stats, I need a library that can be
>> > used for any statistical calculation needed.
>>
>> Are the calculations needed for the GA to work (e.g. as part of a stopping
>> criterion), or are they only meant to inform the user (e.g. for computing
>> current average fitness and the like)?
>>
>> In the latter case, (IIUC) I don't think that we need to introduce such a
>> dependency: Couldn't "out-of-band" functionality be defined through a
>> plugin infrastructure?
>>
>> > I don't want to use the one
>> > from math3 legacy component as that will include all other legacy
>> > components too.
>>
>> If you intend to improve the "genetics" package within the current
>> "commons-math-legacy" module, you can use all the code in there,
>> (including the "o.a.c.math4.stat" package, although that will make it
>> more difficult to create a new module free of those dependencies.
>>
>> Please clarify what goal you are pursuing.
>>
>> > If the commons-statistics component is an isolated one then
>> > that can be re-used once released.
>>
>> I don't understand what you mean.
>>
>> > It will be nice to have a library for plotting graph. Earlier I
>> > used jFreeChart (Lesser GNU Public License), which works fine for this
>> kind
>> > of requirement. Any suggestion regarding this?
>>
>> If you suggest that a Commons component should depend on
>> a plotting library, it's likely "no go".
>> Would a GA implementation need this?
>> Again, if the purpose is to follow progress of the computation, we
>> should define appropriate interfaces to allow data collection in
>> real time. How those are processed (e.g. plotting statistics of the
>> current population) is probably out-of-scope.
>>
>> Regards,
>> Gilles
>>
>> >
>> > Thanks & Regards
>> > --Avijit Basak
>> >
>> >
>> > On Tue, 27 Jul 2021 at 19:33, Gilles Sadowski <gillese...@gmail.com>
>> wrote:
>> >
>> > > Hello.
>> > >
>> > > Le mar. 27 juil. 2021 à 09:15, Avijit Basak <avijit.ba...@gmail.com>
>> a
>> > > écrit :
>> > > >
>> > > > Hi All
>> > > >
>> > > > Please find the proposed changes for the Genetic Algorithm
>> > > library in commons.maths.
>> > > > Changes in Model:
>> > > > 1) GeneticAlgorithm class is broken into a hierarchy to accommodate
>> > > commons implementation in an Abstract class AbstractGeneticAlgorithm.
>> New
>> > > AdaptiveGeneticAlgorithm class has also been introduced.
>> > > > 2) Introduced Elitism interface which is implemented by
>> > > ElitisticListPopulation.
>> > > > 3) Interface Fitness has been removed.
>> > > > 4) Interface FitnessCalculator has been introduced.
>> > > > 5) Chromosome has been updated with FitnessCalculator interface and
>> > > accessor.
>> > > > 6) Operations in AbstractChromosome has been updated with
>> > > FitnessCalculator as interface.
>> > > > 7) New BinaryChromosome class has been added.
>> > > > 8) Interface PermutationChromosome has been replaced by
>> > > IndirectlyEncodedChromosome as the interface primarily represents
>> > > chromosomes with indirect encoding. A more appropriate name can be
>> > > suggested.
>> > > > 9) RandomKey class operations have been updated with
>> FitnessCalculator.
>> > > > 10) I would like to include a new class PermutationChromosome as we
>> have
>> > > corresponding crossover operators like OrderedCrossover.
>> > > > 11) crossover method in CrossoverPolicy interface has been updated
>> with
>> > > additional argument probability to support dynamic probability
>> generation.
>> > > This would impact all implementation classes.
>> > > > 12) mutate method in MutationPolicy has been added another argument
>> > > probability to support dynamic probability generation. This would
>> impact
>> > > all implementation classes.
>> > > > 13) Two new evolution StoppingCondition has been added
>> > > UnchangedAvgFitness and UnchangedBestFitness.
>> > > > 14) An interface ProbabilityGenerator has been introduced with few
>> > > selective implementations to be used by AdaptiveGeneticAlgorithm
>> class. The
>> > > signature of the probability generation method has been kept generic
>> to
>> > > keep strategies interchangeable.
>> > >
>> > > I'd have a hard time commenting as we mostly miss the context: AFAIK,
>> > > nobody here has ever used CM's GA implementation and nobody knows
>> > > how its design structure should be changed in order to improve its
>> > > * usability,
>> > > * performance,
>> > > * robustness,
>> > > * extensibility, or
>> > > * maintenance;
>> > > hence the listing of changes is not very useful without some hint as
>> to why
>> > > things are to be modified, removed or added (e.g. pointing to
>> shortcomings,
>> > > missing features, performance bottlenecks, and so on; and create a
>> JIRA
>> > > report for each of them).
>> > > Actually, I understand that it might be a tedious task, and probably
>> not
>> > > worth
>> > > the modest feedback which you may expect in return. So the best
>> course of
>> > > action is perhaps to implement the new design as you see fit, and
>> then show
>> > > (through applications in "examples" module) how it solves selected
>> > > problems.
>> > >
>> > > Doing so, you could keep us informed of your progress through
>> commenting
>> > > in the appropriate JIRA report(s) and a link to an up-to-date PR.
>> > >
>> > > > I have few more queries related to repository structure.
>> > > > 1) Do we need to keep package name as math4 and not math. Using a
>> > > version-independent name would ease version migration for developers
>> for
>> > > future releases.
>> > >
>> > > Commons has a strict policy of backwards compatibility of minor
>> releases.
>> > > Changing the top-level package's name is done in every major release
>> in
>> > > order to avoid JAR hell.
>> > >
>> > > > 2) Can we have the stat module out of legacy component.
>> > >
>> > > Are you on to fix all the reported issues?
>> > >
>> > > > This can be useful to calculate population statistics if required.
>> > >
>> > > You are certainly welcome to refactor the parts of the "o.a.c.m.stat"
>> > > package which would be of interest for that purpose.
>> > > Please note that redesign statistical functionalities should be ported
>> > > to the "Commons Statistics" component.[1]
>> > >
>> > > Regards,
>> > > Gilles
>> > >
>> > > [1] https://commons.apache.org/proper/commons-statistics/
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > >
>> > >
>> >
>> > --
>> > Avijit Basak
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> --
> Avijit Basak
>
--
Avijit Basak
