Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Changes to user interface in CVXPY 1.0 #199
I'm working on cvxpy 1.0. There will be some changes to the user interface. These fall into three categories:
The first category of changes will be really annoying, but I think they're necessary. The other two should be fairly easy to adjust to.
Post here if you have any other ideas for changes to the user interface or thoughts on the proposed changes.
To be clear, there will be much more exciting new features, but they won't require rewriting any code that uses cvxpy.
I've procrastinated way too long on the cvxpy 1.0 update. I'll aim to finish it this month.
Sets will be a separate type of class. Examples of sets include
When you specify a set's dimensions, this creates a variable that is an element of that set. For example,
like in CVX. The standard
You cannot constrain an expression to lie in a set without the additional equality constraint. The downside of this is that you're always creating an extra variable. The benefit is that it clarifies the issue of dual values. The current contract is that all constraints have a dual value assigned when you solve the problem. If you can create constraints involving non-conic sets, for example
The other function of sets is to specify the domains of variables and parameters. Creating a positive parameter, for example, would look like this
Notice that we don't specify the dimensions of the set, since they can be inferred. To say a parameter belongs to multiple sets, you give the intersection of those sets as the domain. The parameter constructor will use the domain to set the parameter's DCP properties.
For symmetry variables will also have a domain argument, though specifying a set as the domain is equivalent to constructing the variable from that set.
An alternative approach is for
This approach makes more sense mathematically, since sets always have dimensions. It also makes constraints more accessible to the user, since they can create them directly. In proposal 1 there would be a distinction between constraints the user can create and internal constraints that cvxpy can create.
A downside is that only some constraints will have dual values, which might be confusing. Another downside is that set arithmetic might be confusing because people will try to combine expressions and sets. In proposal 1 you can do arithmetic with variables derived from sets, which gives most of the benefits of set arithmetic without the expressions vs. sets issue.
This is really interesting! I hadn't thought about the difficulty in promising dual variables when you allow for general sets.
What's the goal you have in mind for adding sets? Is it adding features (like set arithmetic) or is it that it would clean up a lot of internal code and simplify function definitions? Allowing for general sets and set arithmetic seems tricky, and I don't think I have anything helpful to say.
I do see a benefit to unifying things so that you only have a single type of set and a single type of linear expression, which would both be used internally by CVXPY and by end-users. A third proposal for sets might be something like
The benefits would be that
This proposal wouldn't accomplish as much as your other two, but maybe it would be a good starting point, and some of that other functionality could be added later.
Of course, this is just based on how I was thinking of the problem, so it might not mesh with what you were thinking or trying to accomplish, but hopefully it's helpful.
The main goal in adding sets is to have a unified approach to parameters that belong to special sets (nonnegative, positive semidefinite, etc.) and variables that belong to special sets. This will change the user interface, which is why it's part of the cvxpy 1.0 release.
A secondary goal is to sort out the huge mess that is constraints. Right now there's a distinction between the constraints the user can create (equality, inequality, and positive semidefinite cone constraints) and the constraints cvxpy can create internally. Even worse, there's a third level of constraints that's a half baked LinOp version of equality and inequality constraints.
By adding sets in the style of proposal 2, I hope to reduce the three types of constraints to a single type, which the user can create.
I like your proposal too. I at some point want to get rid of LinOps and define the atoms more elegantly, maybe as partial optimization problems like you suggest. We'll need some way to export a simplified expression tree data structure (like the current LinOp data type) to pass to other libraries, but there's no reason to canonicalize into a special type of expression.
After thinking about it more, I don't think the dual variable issue is a big deal. If someone is sophisticated enough to know what a dual variable is, they can handle the idea that only cone constraints have them.
What do you think of the syntax for proposal 2? Here's how you create a variable constrained to be positive semidefinite:
and here's how you create a parameter with the same constraint:
but that's probably just a personal bias. But since
Steven, both proposals sound awesome. From what I can tell, I think you
Also, might I suggest "CVXSet" as the type? (Are they always going to be
On Tue, Sep 15, 2015 at 5:21 PM, Steven Diamond email@example.com
Yes, and before
Expr.isin is pretty good. It's not enough to modify the contains method,
On Tuesday, March 29, 2016, David Johnston firstname.lastname@example.org wrote:
I just taught a course on convex optimization using cvxpy, and it changed my perspective on cvxpy 1.0. The main issue is that in Python 2.7, NumPy ndarrays are too confusing for people coming from MATLAB. The
ndarrays are more tolerable in Python 3.5 due to the matrix multiplication operator. I could change cvxpy in 3.5 so that
Yeah, it's annoying that you can't define binary operators easily for
There is the "Infix" class hack that you can find by googling. For example
You could also define a function called "mult" or something that would at
import numpy as np
On Sun, Apr 3, 2016 at 6:18 PM, Steven Diamond email@example.com
I guess numpy already has this (multi_dot). See below. There is also the
import numpy as np
On Sun, Apr 3, 2016 at 8:03 PM, David Johnston firstname.lastname@example.org
These are great suggestions, thanks! My main goal is to have code that looks like math, and my secondary goal is to make cvxpy more compatible with numpy. The question is whether these goals are compatible.
My current approach is to use the numpy matrix class in cvxpy, but apparently numpy people are strongly against using the matrix class. If I change cvxpy to return numpy ndarrays, then the difference between cvxpy syntax, where matrix multiplication is
So the question is if I switch to Python 3.5 syntax, what do I do with the Python 2.7 version? Your suggestions are an interesting alternative to the 3.5 syntax that I'll need to think about.
My view is just to follow what NumPy does as closely as possible (e.g.
If CVXPY does something different, than the risk is now there is a 3rd
I also think that the popularity of the numerical python platform has/will
On Mon, Apr 4, 2016 at 1:12 PM, Steven Diamond email@example.com