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
