You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is objectively a bit ugly, perhaps we could support plugin-defined setting presets, so we could have something like:
solver.setSettingsPreset("warm_start")
that under the hood sets the correct parameter in the solver, leaving all the other parameters set to their current values. Having such a flexible method, then the semantics of a given settings preset can be either defined at the qpsolvers-eigen level, or even just for a subset of the solvers plugin.
Another thing that we may want to abstract in general are common settings such as:
Max iterations
Absolute primal tolerance
Relative primal tolerance
In osqp and proxqp these settings have the same name (max_iter, eps_abs, eps_rel) so this is already working fine, but we should also double check if the definition of the tolerance is consistent.
After #15 , if a user is using a solver in a warm start setting, it needs to call the following code:
This is objectively a bit ugly, perhaps we could support plugin-defined setting presets, so we could have something like:
that under the hood sets the correct parameter in the solver, leaving all the other parameters set to their current values. Having such a flexible method, then the semantics of a given settings preset can be either defined at the
qpsolvers-eigen
level, or even just for a subset of the solvers plugin.fyi @LoreMoretti @GiulioRomualdi
I think it could be worth to understand how to integrate this and #8 .
The text was updated successfully, but these errors were encountered: