The NonPos constraint class #2153
Replies: 2 comments 1 reply
-
I started writing something long about Boyd and Vandenberghe conventions, but then it hit me: it is important to differentiate the dual variables of constraints of the form "f(x) <= g(x)" with f convex, g concave and conic constraints conceptually. Conic constraints in my mind should make sense in a conic sense, eg a self-dual cone should be have dual variables inside the cone. Trying to closely resemble a functional implementation with the constraints feels not particularly productive to me. |
Beta Was this translation helpful? Give feedback.
-
We decided to deprecate NonPos in favor of NonNeg: #2155. |
Beta Was this translation helpful? Give feedback.
-
@aryamanjeendgar and I are trying to add support for checking if a Lagrangian is stationary at a claimed primal-dual optimal solution. This is tricky because CVXPY doesn't formally define a Lagrangian from a user's perspective, and Lagrangians are subject to sign convention on the dual variables. So we've proceeded by assuming the current dual variables are correct up to signs, and we're writing code to construct the Lagrangian as a CVXPY Expression.
We've found that for all conic constraints except NonPos, the appropriate term to add to the Lagrangian is
- cp.scalar_product(con.args, con.dual_value)
. However NonPos needs+ cp.scalar_product(con.args, con.dual_value)
.Weirdness in the way NonPos defines dual variables
NonPos.dual_value
always returns nonnegative numbers. This is weird because the cone of nonpositive real numbers is self-dual (i.e., we should expect nonpositive dual variables). The reason for its current behavior stems from a convention established long ago, that(expr <= 0).dual_value
should matchNonPos(expr).dual_value
. You can see that this is the convention because we explicitly test for it here.What, if anything, should we change?
This convention of nonnegative dual variables for NonPos seems reasonable on the surface, but I think it misses important semantic distinctions between conic constraints and inequality constraints specified with functions.
This all has me thinking about if some changes to NonPos might be in order. Maybe we should define its dual variables differently to actually work with the dual cone. Maybe we should modify CVXPY's internal code so that
NonPos
objects are only constructed in tests (never in "functional" or "operational" code). If we go this latter route, maybe we should deprecate NonPos and raise a warning if a user constructs a NonPos object.What are your thoughts, @SteveDiamond, @phschiele, @akshayka, @PTNobel, @bstellato?
Beta Was this translation helpful? Give feedback.
All reactions