Hello Nanubala, welcome, great work on #269 and #263.
> My thoughts are, we could: > 1) Create separate classes for CrossOvers, Mutations etc. > 2) Use templates to access their functionality (much like the KernelType > Policy <https://www.mlpack.org/doc/stable/doxygen/kernels.html>) Using the policy-design pattern sounds like a good idea to me, one reason why we haven't done this for the existing evolution-based optimizers is that they slightly differ in functionality, but I can see that if we are going to implement more optimizers that a restructure make sense especially if we can avoid code-duplication. > During my GSOC I plan on > a) Creating policy based structuring to outsource operator functions. > b) Restructure currently implemented algorithms to fit to this principle > c) Miscellaneous: Add more multiobjective algorithms. I am interested to see if you have some method in mind for c). Implementing a new optimizer can take some time, so we should make sure the selection is reasonable in the context of the GSoC timeline. Thanks, Marcus > On 10. Mar 2021, at 16:52, Nanubala Gnana Sai <[email protected]> wrote: > > Greetings! Team mlpack. > > I'm Nanubala Gnana Sai from the Indian Institute of Information Technology, > Sri City. My IRC-Channel ID is @jonpsy. For quite some time, I've been > contributing to mlpack, more specifically to the MOO algorithms of ensmallen. > #269 <https://github.com/mlpack/ensmallen/pull/269> #263 > <https://github.com/mlpack/ensmallen/pull/263>. > > During my work, I've taken references from multiple resources like Pagmo > <https://esa.github.io/pagmo2/>, pymoo <https://pymoo.org/>, DEAP > <https://deap.readthedocs.io/en/master/> and research papers. I couldn't help > but notice these inefficiencies > > * Operators like Crossover, Mutation etc. are implemented per algorithm. > * This causes bloated coated and increases potential errors. > > I really like how others, for ex: DEAP approaches this, they've implemented > all the varieties of operators on a separate module > <https://deap.readthedocs.io/en/master/tutorials/basic/part2.html> which can > be called on by the optimizer. Upon reading our style guide, I think this > fits perfectly with our policy based design principle. > > My thoughts are, we could: > 1) Create separate classes for CrossOvers, Mutations etc. > 2) Use templates to access their functionality (much like the KernelType > Policy <https://www.mlpack.org/doc/stable/doxygen/kernels.html>) > > During the past year, I've contributed to shogun repository extensively so I > have exposure building OOP-based structures, although admittedly I'm new to > the policy-based design principle. > > During my GSOC I plan on > a) Creating policy based structuring to outsource operator functions. > b) Restructure currently implemented algorithms to fit to this principle > c) Miscellaneous: Add more multiobjective algorithms. > > Suggestions and criticism are welcome! > > > Best > NGS > _______________________________________________ > mlpack mailing list > [email protected] > http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
_______________________________________________ mlpack mailing list [email protected] http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
