-
Notifications
You must be signed in to change notification settings - Fork 40
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
need GP class as data model #7
Comments
RE: 'matrix of exponents associated with each constant in each constraint' I think the GP class should have a 'constants' attribute that it applies to its purely symbolic representation of the cost and constraints before solving, and an 'update' function. This would look something like: GP = gpkit.GP(cost, slf+other_constraints, constants)
sol1 = GP.solve()['solution']
# change the constraints...
GP.update(constraints = new_constraints)
sol2 = GP.solve()['solution'] # also stored at GP.solution
# change the constants...
GP.update(constants = new_constants)
sol3 = GP.solve()['solution']
# change the cost function and merge with another GP
GP.update(new_cost, new_GP.constraints, new_GP.constants)
# the GP class will have automatically generated and efficiently kept up-to-date:
# - a sparse A matrix (called F by CVXopt)
# - a c vector (called g by CVXopt)
# - a map vector for MOSEK
# - a 'k' vector for CVXopt, because I can't see of a clean way to do without it
sol4 = GP.solve()['solution'] |
yes, like everything we're outlining here. |
I implemented it just as above except that GP.solve() does not return a dictionary, but the primal solution. Everything in the original request has been covered... |
We need a class that represents a GP (or a 'GP constraint set', if we decide we don't want it to include an objective). This ticket is a placeholder to get some ideas down on paper -- it probably needs to be split into multiple sub-tickets as we flesh these issues out.
The GP class should support:
The data model (A, c, map) should probably match MOSEK instead of CVX, for efficiency once we get mosek working. And we presumably want ways of going back-and-forth while still supporting fast re-solve.
The text was updated successfully, but these errors were encountered: