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
