This part assumes the reader went through the Design choices and libraries' internals page and is familiar with the user interface.
The first step is determining if there is any interest in integrating the solver.
The solver should target one of the following optimization problem's:
...with or without constraints.
It should also support bounds and scales. If not, emulating them should be possible.
Integrating solvers that solve very different problems will likely not match the interface and lead to major changement in the package. These changes are beyond the scope of this document and should be discussed on the mailing-list.
Basically, adding a new solver means adding a new leaf in the solver hierarchy.
The new header and source files should be added in the src
directory.
The naming convention is CamlCase, the name should be the solver's name suffixed by Solver
.
This plug-in must be provided as a separate package to avoid cluttering RobOptim Core with useless dependencies.
The first step is choosing from which Solver
you want to inherit from. The F
parameters should be straight-forward: it is the kind of objective function you expect. For the constraints, there is two cases:
C
to const MyConstraintType*
where MyConstraintType
is the solver's constraints type. C
should be: boost::variant<const MyConstraintType1*, const MyConstraintType2*>
Then, the solve
method should be implemented in the bridge.
Following guidelines should be respected by any bridge:
reset
if the result has to be recomputed the next time getMinimum
is called. solve
put the computed value in the result_
attribute. print
method to display internal state. The dummy solver can be a good starting point for anyone who wants to add a new solver as the code can be considered as the minimum stub to get a compilable bridge. It should also be quite easy to understand.
If you write a new bridge, please post an annoucement to the RobOptim Google group.