implementation of compareStatistics should consider user-specified tolerence settings
Opened this issue · 2 comments
I'm using ECOS with CVXPY to solve minimization problems over the exponential cone.
I found a strange situation where ECOS returned an optimal value of -17.8, when the value returned by a heuristic solver (from SciPy) found a feasible point of value -18.2. After further investigation, ECOS did find a point with objective value -18.2 (see below), but it didn't consider that the "best" iterate.
It pcost dcost gap pres dres k/t mu step sigma IR | BT
2215 +1.787e+01 +1.787e+01 +3e-14 3e-05 2e-09 1e-08 3e-17 0.4010 1e+00 0 1 1 | 22 4
11208 +1.819e+01 +1.819e+01 +6e-14 2e-06 8e-10 8e-08 5e-17 0.0000 1e+00 1 0 0 | 89 83
Close to OPTIMAL (within feastol=2.7e-05, reltol=1.8e-15, abstol=3.2e-14).
Ordinarily- that's fine. Picking the best iterate with an infeasible primal-dual solver is an art, and it's true that iterate 2215 above had smaller duality gap than iterate 11208.
The problem occurs when I change ECOS settings to require feastol_inacc=5e-6. In this situation, many iterates (those around 11,000) do satisfy the criteria for an inaccurate solution, while the "best iterate" selected by "compareStatistics" does not satisfy the criteria for an inaccurate solution. As a result, with feastol_inacc=5e-6, ECOS throws an error even though it found many points which satisfy the criteria for an inaccurate solution.
I think that "compareStatistics(infoA, infoB)" should return "1" if infoA satisfies precision criteria when infoB does not, regardless of how the statistics would otherwise be ranked.
@adomahidi, this is a year late. But this is a valid concern. What do you think?
This also involves the exponential cone bits which @tiagoakle wrote, so maybe he can give some guidance. I think @adomahidi would be happy to take a PR for this.
It's definitely a valid concern, and should be corrected. @rileyjmurray (or someone else) if you propose a PR I am happy to take the time to review and merge.