-
Notifications
You must be signed in to change notification settings - Fork 87
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
Implement Utilities.distance_to_set for more sets #2033
Comments
can you be more specific in what did not work on using the PowerCone from MOSD? |
Well it didn't solve the not implemented error. After i ran
|
You probably need to patch it with: JuMP._distance_to_set(var::Vector{Float64},cone::MathOptInterface.PowerCone) = MathOptSetDistances.distance_to_set(MathOptSetDistances.DefaultDistance(), var, cone::MathOptInterface.PowerCone) I think you forgot the |
We've intentionally avoided implementing distances for conic sets, because it was non-obvious what distances to use. I have to apologize to @matbesancon every time I bring this up, but if you want the backstory, go get a cup of coffee, then read #1023. |
Wearing my user hat it would be acceptable for me if loading some package that includes An alternative might be to use sign(distance_to_set) as that as invariant under different distance metrics. 0 is on boundary, negative inside, positive outside. |
why would you need this? If you care about feasibility checking you just want the non-zeroeness of the distance in itself |
Well you are right you don't need a "signed distance function". My bad. |
So I guess the ask is for MOI.Utilities to provide |
That would be nice. If i have to include one package like |
I'll move this to MOI, since this is where we'd add the functionality. |
Assuming we merge #2048, what distance would we use for this? MOSD uses: |
I think we established that what distance is used doesn't matter for the sake of feasibility checking as long as it implies the same discrete metric under ==0. |
@matbesancon what are your thoughts on this? We could potentially add MathOptSetDistances as a pkg extension? |
yes that makes sense. The current dependencies are:
|
one of the key things to use these functionalities in solvers would be an in-place version of the projection to set |
Not sure it should be a Pkg extension with these extensions, it's weird to have to import |
the other big functionality of SetDistances is the implementation of ChainRules for the projection gradient. Maybe this can be a separate extension |
What does this have to do with it? You'd need |
I meant add a |
and StaticArrays is lightweight enough to bring along, no? |
I don't understand what |
Then I'm missing something. What's the content of the package extension then ? Are we going to move part of the code of MOSD into the package extension and keep part of it in MOSD ? |
The extension would be: module MathOptInterfaceMathOptSetDistancesExt
import MathOptInterface as MOI
import MathOptSetDistances as MOSD
MOI.Utilities.distance_to_set(x, s) = MOSD.distance_to_set(MOSD.DefaultDistance(), x, s)
end That's all. It avoids type-piracy in MOSD, and it avoids MOI having to re-implement everything. |
The name is a tad annoying. I hope no user has to type that. |
What name? |
For which set is |
Indeed, I think it's simpler to move them to MOI rather than having a package extension. |
Is your feature request related to a problem? Please describe.
I have a model which contains a MathOptInterface.PowerCone and want to verify a the primal feasibility of a point.
Describe the solution you'd like
Support feasibility checking of all standard sets maintained by jump-dev. Short term i need a workaround.
Describe alternatives you've considered
I considered monkey-patching
_distance_to_set(var::Vector{Float64},cone::MathOptInterface.PowerCone) = distance_to_set(var::Vector{Float64},cone::MathOptInterface.PowerCone)
from MathOptSetDistances by @matbesancon however that did not work.The text was updated successfully, but these errors were encountered: