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 problems:
...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 change 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
The naming convention is CamlCase, the name should be the solver's name suffixed by
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 parameter should be straightforward: it is the kind of objective function you expect. For the constraints, there are two cases:
MyConstraintTypeis the solver's constraints type.
boost::variant<const MyConstraintType1*, const MyConstraintType2*>
solve method should be implemented in the bridge.
Following guidelines should be respected by any bridge:
resetif the result has to be recomputed the next time
solveputs the computed value in the
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.