Comments (6)
cc @hongkai-dai, @cohnt , @RussTedrake, and @sadraddini as all of you may have thoughts.
from drake.
+1 from me on this. I can think of multiple cases where I would leverage this!
from drake.
A draft PR is available at #21253 to discuss the design. An example of changing the method in HPolyhedron
is also provided.
from drake.
It is indeed useful. However, I feel that such an API is not right, as convex set object instances will carry extra information. Many convex set methods do not rely on optimization. I still prefer a more direct API such that for each method that solves a mathematical program, the user can specify the solver. Also, the user may want to use different solvers for different methods with the same ConvexSet
object. That can be achieved with convex_set->SetSolverInterface(foo)
or convex_set->SetSolverOptions(foo)
, but feels unnatural. Again, I agree that this eventually will be useful. My comments is only about style.
from drake.
For the design with the solver as a shared_ptr member field of ConvexSet, it also raises difficult questions about thread safety. Previously, if I took a ConvexSet object and handed it off from one thread to another, the other thread could do as it pleases. If the solver is a shared_ptr member field, now we have possibly many sets on different threads all trying to call the same solver instance, which is not threadsafe.
On the other hand, the solver options can easily be either const or copied around, so do not raise questions about thread safety.
Still, aesthetically I agree with @sadraddini that having the options come in as arguments to one specific operation at a time is likely to be more sensible. If we could see some examples of how this would be used, that might sway the API design one way or another.
from drake.
Thank you all for commenting on the API, as I don't necessarily think my way is the best way. My high level goals with the current design was to avoid having to specify the solver instance every time a method is called. The other awkwardness I see with having the SolverInterface/SolverOption
as an argument in each method at the ConvexSet
level is that it may mistakenly give the impression that we do not provide efficient implementations for some operations.
The simplest example of this is the PointInSet
method. Checking membership in a VPolytope
will always require solving an LP and so at the ConvexSet
interface level, we should allow specifying a SolverInterface
and some SolverOptions
. However, checking membership in an HPolytope
is done without solving an optimization program i.e. just checking that Ax <= b
is true and so it would be awkward to allow users to pass these spurious arguments.
Thoughts on how to resolve this?
That is a very good point about the shared pointer. @jwnimmer-tri I suppose copyable_unique_ptr
may be the way to go with this design instead? I want to still be able to clone ConvexSet
so I do need copy semantics .
from drake.
Related Issues (20)
- Issues converting HPolyhedron to VPolytope HOT 5
- SAP failure case with Newton line search HOT 2
- Release v1.29.0 to Docker HOT 1
- OpenUSD compilation errors on Ubuntu 24.04 HOT 1
- Inconsistent port names in MultibodyPlant HOT 1
- Nonlinear GCSTrajectoryOptimization
- Remove solver-specific builds in CI (snopt, mosek, gurobi) HOT 1
- Noble Provisioned AMI HOT 2
- Update CI Mosek license
- SDFormat include of URDF treats warnings as errors HOT 3
- Updated macOS Provisioned images HOT 2
- [ci] Config changes for Noble support HOT 7
- Enable SPRAL(+METIS) option for IpoptSolver
- Getters for MultibodyConstraintId for constraints added by the Parser
- Need to document the MultibodyPlant generalized_contact_forces output port
- Strange handling of constraints with IPOPT. HOT 2
- repack_deb support for Noble HOT 1
- Need to run Command Line Argument Twice for Example to Properly Play HOT 1
- Increase the number of quadrature points used to sample external forces in FEM deformable simulation
- Misleading usage of auto-generated compliant hydro meshes with convex shapes HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from drake.