pagmo
pagmo copied to clipboard
esa
Algorithm-Problem compatibility simplification
Right now, at the beginning of each evolve method of the classes deriving from algorithm, we check whether the algorithm is compatible to the problem (mo, integer, contsraints) .... this should insted go in the base class.
A new data member of the base algorithm class should be added containing a struct or something with boolean fields like multi_objective, constrained, integer, continuous, etc..... in the base evolve method this should be checked for compatibility with the problem.
A pure virtual method should then be charged to construct such a data member as to force the user to define the algorithmic type at construction.
@darioizzo Hello, could you please provide a sample code snippet of how you think the user should provide the algorithmic type (I'm thinking having a custom enum with the OR operator overloaded, but that seems like an unusual solution; or maybe better: variable argument function...)?
To clarify, do we want to add the compatibility checking code in algorithm::base::evolve()? I'm asking because currently, algorithm::base::evolve() seems to be purely virtual. If we define it and add the compatibility checking code there, and not in any of the derived algorithm::X::evolve() methods, it would still be the responsibility of the user to call base::evolve() when creating new algorithms.
Would it then make sense to use instead a similar paradigm of base method vs implementation as found in problem::objfun vs virtual problem::objfun_impl?
Eg. the user overwrites objfun_impl but all internal methods call objfun (which in turn calls objfun_impl).
Yes. One could have the method evolve calling a pure virtual method evolve_impl reimplemented in derived classes. The check would then be in evolve.
Right ok, one more question then: how would that affect current derived algorithms that reimplement evolve()? Will they remain unchanged, in which case we would end up with two virtual functions: evolve() and evolve_impl()? This would be slightly different from problem class where objfun is non-virtual, private and objfun_impl is pure virtual.
Alternatively, we could change all class definitions of evolve into evolve_impl and have evolve non-virtual. Code which calls evolve will remain unchanged. However, wouldn't this mean all documentation need to be updated to inform users that evolve_impl should be reimplemented instead?
No you would have to rename all evolve methods in the derived classes to evolve_impl. Also you would have to define for each algorithm the new bool values that will be checked