The feature/variable_naming PR seems very good; the one here performs some minor changes on it:
minor changes in the PR (Verbosity changes: warnings are not printed by default)
And the following shoud be checked (Baptiste)
for unit tests without MOSEK: it takes forever ! Also, some output by CVXPY: "UserWarning: Solution may be inaccurate. Try another solver, adjusting the solver settings, or solve with verbose=True for more information. warnings.warn("
for "relative duality gaps" -> mb check if relevant? This might be problematic in cases where either primal or dual is zero (it is actually the case for a few examples involving Lyapunov/potential functions; e.g., PEPit/examples/continuous_time_models/gradient_flow_convex.py)
the "solve" from PEP does not return a guarantee: it returns the value of the primal problem, not that of the dual one. It should either return the dual one (at least for all examples: if we claim "f(x)-f_*\leq XXX", XXX must be the dual value computed; one of the referee explicitly asked this, and this is, philosophically, the honest thing to do; even if it does not change much)
there is one test not passing in it...?
with Aymeric: please discuss & update the "list of contributors" + descriptions of the contributions in the README.md
it seems to me that when decomposing the matrix G (for evaluating x's, etc.), the eigenvalues are not ordered (so the nonzero component in x_k's are not the first components appearing when evaluating them); possible to check/fix (issue already raised several times)
In all smooth or Lipschitz classes of functions (and Lipschitz or cocoercive operators) have default parameters set to 1. (except BlockSmoothConvexFunction). I believe there should NOT be default parameters (default is np.Inf) ! Or at least mention it in documentation?
The feature/variable_naming PR seems very good; the one here performs some minor changes on it:
And the following shoud be checked (Baptiste)