-
Notifications
You must be signed in to change notification settings - Fork 4
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
Migrate from cvxopt to cvxpy (+osqp / clarabel) #8
Conversation
@fabian-sp Replaced cvxopt with cvxpy. Equality constrained tests are still failing. Update: Line 600 in f79b0db
|
For the record: the -1 was indeed incorrect, should have been a +1. |
@phschiele Did you run
|
Comparing main to this branch on the rosenbrock timing, I get:
So somehow there seems to be some overhead/slower solving time due to cvxpy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some questions/comments, but can be merged
@@ -26,7 +26,8 @@ classifiers = [ | |||
dependencies = [ | |||
"numpy", | |||
"torch", | |||
"cvxopt", | |||
"cvxpy-base", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not cvxpy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CVXPY comes with multiple solvers by default. cvxpy-base
is only the modeling language itself, and we only install one solver (clarabel
) explicitly. This makes maintenance a lot easier.
H: np.ndarray, | ||
rho: float, | ||
D_f: np.ndarray, | ||
D_gI: list[np.ndarray], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My VS Code complains about the list
, probably prefers the List
form typing?
""" | ||
The quadratic subrpoblem we solve in every iteration is of the form: | ||
@property | ||
def problem(self) -> cp.Problem: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the ruleset on whether to define a property or to initialize in the __init__
? To me this looks slightly overcomplicated...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did it this way to prevent users from having to check if the problem has been initialized yet every time, since in the __init__
you would set it to None
, right?
|
||
from ncopt.sqpgs.main import SubproblemSQPGS | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the tested subproblems somehow special (that is, coming from a special case of the underlying problem)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are the first iterates of the rosenbrock example, so not special.
Checklist: