Hi All
Please find my comments below.
[...]
>Just quickly commenting on this point.
>IIUC, your purpose is for users to be able to run (an example
>application of) the old implementation.
>
>This can be achieved by having all the "legacy" codes within
>module
> commons-math-examples/examples-ga/examples-ga-math-functions
>(note: No "legacy" in the module's name), within a dedicated
> o.a.c.m.examples.ga.mathfunctions.legacy
>package.
>
>This code is then called by the exact same code/application as
>for the new implementation (with the corresponding command
>line switch):
> $ java -jar examples-ga-app.jar --legacy ... rest of the args ...
>
>Users can thus perform 2 runs; once with "--legacy" and one
>without it, and reach some conclusions.
>
>The duplicate codes only bring maintenance burden (to ensure
>that the "legacy" and non-"legacy" modules do indeed aim at
>solving the same problem).
>Whenever we then decide that the new code has been thoroughly
>tested, removal of the
> o.a.c.m.examples.ga.mathfunctions.legacy
>package will be a minimal change (as compared to the removal
>of a module)
--I have made the changes and created a new PR. Kindly review the same and
share your thoughts.
*https://github.com/apache/commons-math/pull/208
<https://github.com/apache/commons-math/pull/208>*
Thanks & Regards
--Avijit Basak
On Mon, 28 Mar 2022 at 18:36, Gilles Sadowski <gillese...@gmail.com> wrote:
> Hello.
>
> Le lun. 28 mars 2022 à 10:15, Avijit Basak <avijit.ba...@gmail.com> a
> écrit :
> >
> > [...]
> >
> > >The various "Standalone" classes also look quite similar; consolidating
> the
> > >"examples-ga" module (including full Javadoc) is necessary.
> > -- Could you please elaborate it more. IMHO as StandAlone classes are
> > dedicated to the specific module only, it would remain separate. Since we
> > have used a single domain to show utility of the different
> > types(adaptive/simple) of GA some classes have become similar.
> >
> > >I still don't
> > >understand why there are "...-legacy" modules in module "examples-ga".
> > >If you want to offer the option of running the "old" implementation, you
> > >could add a "legacy" flag (as "@Option" in the "Standalone"
> application).
> > -- There was a discussion on this some time back. The sole purpose of
> > keeping the legacy example module is for comparison with the new
> > implementation. It will be easier for anyone to visualize the quality
> > improvement we achieved here. I don't want to mix(by legacy flag) this
> > anyway with the new implementation.
> >
>
> Just quickly commenting on this point.
>
> IIUC, your purpose is for users to be able to run (an example
> application of) the old implementation.
>
> This can be achieved by having all the "legacy" codes within
> module
> commons-math-examples/examples-ga/examples-ga-math-functions
> (note: No "legacy" in the module's name), within a dedicated
> o.a.c.m.examples.ga.mathfunctions.legacy
> package.
>
> This code is then called by the exact same code/application as
> for the new implementation (with the corresponding command
> line switch):
> $ java -jar examples-ga-app.jar --legacy ... rest of the args ...
>
> Users can thus perform 2 runs; once with "--legacy" and one
> without it, and reach some conclusions.
>
> The duplicate codes only bring maintenance burden (to ensure
> that the "legacy" and non-"legacy" modules do indeed aim at
> solving the same problem).
> Whenever we then decide that the new code has been thoroughly
> tested, removal of the
> o.a.c.m.examples.ga.mathfunctions.legacy
> package will be a minimal change (as compared to the removal
> of a module).
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
Avijit Basak
