[mlpack] [GSOC] Restructing Multi Objective Optimization Module

[Marcus Edel]

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 <gnanasai.n18 at iiits.in> 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
> mlpack at lists.mlpack.org
> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://knife.lugatgt.org/pipermail/mlpack/attachments/20210311/c5548af6/attachment-0001.htm>