-
Notifications
You must be signed in to change notification settings - Fork 7
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
Numerical Issues with StrongSmoothlyConvexQuadraticFunction #97
Comments
As a followup to this, we were able to use the mosek wrapper directly by try-catching the AssertionError and then extracting the solution from the |
Thank you @vinitranjan1 for raising this issue! We are currently in deadline mode, but we have started looking at it and will get back to you ASAP! |
@vinitranjan1 Thanks again! With the direct interface to MOSEK, the following quick (dirty) fix seems to "work" (I've added the line xs_f2 = func2.stationary_point() to force the existence of an optimal point for the quadratic function), but I'll dig more into it and come back to you within the following days. The following code might not be the thingthat ultimately does what we want (so I would not use that in a paper just now; we have to investigate it a bit more & provide a fix) , but at least parts of origin of the bug are clear. Thanks a lot again! `
`` @NizarBousselmi It would be nice if you could check the codes implementing quadratic interpolation [also not with the implicit assumption that x_*=0 which was in your original pull request]. |
Hello, @vinitranjan1! Unfortunately, some problems remain (mostly due to problems on the solvers' side). There is quite a bit of sensitivity in the output, so K should not be too big and the step size should stay reasonable as well (also not too small). Overall, the conclusion seems to be that
|
Hello @AdrienTaylor and @NizarBousselmi,
First, thank you for creating this library!
I am working with @bstellato on verification methods specific to parametric QPs here and used PEPit for comparison purposes in our paper.
While working with the
StrongSmoothlyConvexQuadraticFunction
object, I ran into numerical issues with the following example:Solving with the mosek wrapper directly.
In this case, with
I notice that the code errors out with an assertion error in the feasibility check for the
PEP
object:It seems that the final value from Mosek is extracted incorrectly when performing the check as the
wc_value
is 0 butself.objective.eval()
correctly retrieves the answer from Mosek.Solving through CVXPY
However, when solving through CVXPY to try other solvers, I noticed numerical issues.
When running the same instance with an uncommented line, either
or
the solvers error out with numerical issues when using the default tolerances.
For example, Mosek reports
and Clarabel reports
It seems there is some numeric issue in the problem formulation that gets fed into cvxpy. When using a more general class such as
SmoothStronglyConvexFunction
for example, all of these issues disappear and the three methods agree.The text was updated successfully, but these errors were encountered: