[Feature Request] An abstraction for eoSGA operator()

[ropinho]

eoSGA

eoSGA provides simplicity, but not freedom to implement the genetic algorithm internally, for this there are other features with higher learning curve.

My idea for this feature is:

A derived class from eoSGA that provides the possibility to implement its own operator()(eoPop<EOT>&).

In this case the class would get a pointer to a function implemented by user that uses the eoSGA attributes, and the operator() of the class would call this function.

OBS: the access to eoSGA attributes should be changed to protected.

Derived class from eoSGA

Example:

template <class EOT>
class ExampleGA : protected eoSGA<EOT> {
public:
    ExampleGA (/* {eoSGA args} */, void (* _func)( eoSgaArgs, eoPop<EOT>& ))
    : eoSGA<EOT>( eoSgaArgs ), implFunc(_func) {}

    void operator()(eoPop<EOT>& _pop) {
        (*implFunc)(eoSgaArgs, _pop);
    }

protected:
    /*same protected attributes */
    void (* implFunc)( eoSgaArgs, eoPop<EOT>& );
}

Considering eoSgaArgs as all args that get from eoSGA class.

The objective of this would be provides more freedom and flexibility on internal implementation to genectic algorithm. This way is the better way to create the your own GA if you want freedom to implement, without need learn an amount of classes implementation.

What you think?

[nojhan]

I did not quite get the problem you are trying to solve, here.

If the problem is the complexity of having to choose the operators to embed in an eoAlgo, then it's more a documentation problem (which is a very big problem in ParadisEO, indeed).

If the problem is the ability to implement whatever algorithm, without bothering with operators, then it renders the whole point of the framework quite useless. But if you really want to do this (for instance to use only, say, the monitoring operators) then you still can inherit from eoAlgo, or even implement you own class and just use some other operators.

The first point of ParadisEO is that it's handy when you want to design your own algorithm but you want to be able to rapidly test alternative operators. This comes at the (expensive) cost of a steep learning curve and the need of a good documentation. But if you just want to do a proof of concept of a single random algorithm without having to bother for the algorithm architecture (or alternatives- and with side features (logging, monitoring, parallelization, etc.), then I would say you'd better off with a simple python script.

IMHO, the biggest problem with ParadisEO as of today is that the documentation is a bit old, does not cover all modules in the same way and needs an overall integration with a single entry point and a good FAQ (or HOWTOs). Having a better documentation would help newcomers to realize the point of the framework. And for that, hints from newcomers (like you) is invaluable: just taking some time to raise issues that are not clear could help us to improve the documentation (or you can even write some once you understand).

P.S. On the code design side, I suggest you'll have a look at variadic arguments and std::function that might help you improve your C++fu.