[mlpack] [GSOC] Restructing Multi Objective Optimization Module

[Nanubala Gnana Sai]

Thanks for the valuable feedback!

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
>

 I was pondering about the same situation. One of the key problem, the
number/type of arguments may differ for each policy of the same type. For
instance, DE crossover and SBX require different arguments. Taking
inspiration from DEAP, I figured we should do the following:

Step 1) Create a wrapper around map to create and store argument during
runtime.
Step 2) Initialize the policy with its argument in the driver file. These
arguments are given through template for ex: ```template<CrossOverPolicy =
DE<3, 0.4>>```
Step 3) The policy would take two inputs
        i) The argument map: Stores the runtime argument like current
populationIdx etc.
        ii) The problem: Stores info about lowerBound, upperBound. This can
be used for repair heuristic.

What does it solve?
1) Avoids lengthy argument passing to ctor.
2) Args are confined to where they are needed. Ex: CrossOver args are given
to policy instead of optimizer ctor.
2) Code is more generic. Easily change the crossover, mutation etc. strategy
*.*
3) And ofcourse, reduces code bloating.

I think I should create an issue to better address this.

I am interested to see if you have some method in mind for c)
>

Strength Pareto Evolutionary Algorithm and NSPSO(Non dominated sorting PSO).


Finally, I realize that this could be a lot of work. So I want to choose
between either refactoring or adding the new algorithms. I'll keep the
scope short so that we can guarantee successful completion of GSoC :)

Best
NGS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://knife.lugatgt.org/pipermail/mlpack/attachments/20210313/2fd4a483/attachment.htm>