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
_______________________________________________ mlpack mailing list mlpack@lists.mlpack.org http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack