Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add method to set many parameters by passing a single string #8

Open
traversaro opened this issue Nov 8, 2024 · 6 comments
Open

Add method to set many parameters by passing a single string #8

traversaro opened this issue Nov 8, 2024 · 6 comments

Comments

@traversaro
Copy link
Contributor

For integrating with https://github.com/robotology/wb-toolbox, we need some way to pass arbitrary parameters (as we do not know in advance the parameters that will be available in a given solver) via single string.

For example, in place of:

    // Set osqp-specific parameters
    solver.setBooleanParameter("verbose", true);
    if (solver.getSolverName() == "osqp")
    {
        solver.setRealNumberParameter("alpha", 1.0);
        // See https://github.com/robotology/osqp-eigen/pull/172
        solver.setBooleanParameter("polish", true);
    }

we could use either a json string:

solver.setParametersViaJsonString("{\"verbose\": true, \"alpha\": 1.0, \"polish\": true}");

or toml inline table (https://toml.io/en/v1.0.0#inline-table):

solver.setParametersViaTomlString("parameters = { verbose = true, alpha = 1.0, polish=true }");

I am inclined more to the toml inline table, as there are less double quotes involved (none if you do not use string parameters) and potentially is more easy to integrate (and copy&paste back and forth) parameters from BLF's ParamHandler Toml backend.

Probably we can also provide a setting on either ignore or raise an error if an unknown setting is passed, as there are use case for both cases: one one hand ignoring unknown parameters make it simple to have a single string with settings for multiple solvers, so switching solvers only requires changing the solver name, but it opens the door of bugs caused by typos, that can be prevented if one specifies that unknown parameters should raise an error.

@traversaro
Copy link
Contributor Author

@S-Dafarra
Copy link
Member

Probably we can also provide a setting on either ignore or raise an error if an unknown setting is passed, as there are use case for both cases: one one hand ignoring unknown parameters make it simple to have a single string with settings for multiple solvers, so switching solvers only requires changing the solver name, but it opens the door of bugs caused by typos, that can be prevented if one specifies that unknown parameters should raise an error.

This is a behavior that can enabled/disabled by with an additional parameter I guess

@traversaro
Copy link
Contributor Author

Yes,

@GiulioRomualdi
Copy link
Member

I also vote for the toml parser. If I'm not mistaken toml is already a dependency of the superbuild

@traversaro
Copy link
Contributor Author

I also vote for the toml parser. If I'm not mistaken toml is already a dependency of the superbuild

I think in the superbuild we pull also somehow (I think with apt/conda) nlohmann-json, but indeed toml seems a better option.

@traversaro
Copy link
Contributor Author

I wonder if this may be also useful to easily pass a group parameters in a structured way between a BipedalLocomotion::ParametersHandler and a QpSolversEigen::Solver without having to add any mutual dependency. Or perhaps they could only share some logic (such as the methods that get all the supported parameters for a given type for each solver, that for sure is required by this functionality).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants