I tried CVX 3.0beta with Mosek 9.0, and I have a valid individual academical license of Mosek 9.0. It turns out that CVX 3.0beta can not find it, but CVX 2.1 can. Is this normal? Does anyone have this problem?
My understanding of http://cvxr.com/news/2018/12/important-announcement-academic-license-changes/ is that this licensing model is only possible with the latest 2.1
Thanks, I think so. BTW, do you know how to fix this “cvxobj” problem when installing? http://ask.cvxr.com/t/error-in-installation/5245
3.0beta is supposed to be quite buggy. Unless you can fix bugs yourself it might be a good idea to use it.
I do not think I have that ability to fix the bugs myself lol! I wanted to to use CVX 3.0beta because I thought it would work if CVX 3.0beta is combined with Mosek 9.0 to solve naive EXP cone programming. Now I go back to CVX 2.1 and everything goes well. Thanks!
As @Erling wrote, CVX 3.0 beta is very buggy. It does have the ability to use the native exponential cone capability of SCS and ECOS. But there is no build of CVX which currently uses Mosek 9.0’s native exponential cone capability.
I recommend you use CVX 2.1, with Mosek 9.0 as solver, and install CVXQUAD and follow the guidance at CVXQUAD: How to use CVXQUAD's Pade Approximant instead of CVX's unreliable Successive Approximation for GP mode, log, exp, entr, rel_entr, kl_div, log_det, det_rootn, exponential cone. CVXQUAD's Quantum (Matrix) Entropy & Matrix Log related functions . I see from a previous question that you have already installed CVXQUAD.
Yes, I am now using CVXQUAD, but the running time is still a little long. I tried to find some other ways to make it shorter.
YALMIP does exploit Mosek 9.0’;s native exponential cone capability. https://yalmip.github.io/tutorial/exponentialcone/ I;m guessing that will be faster than CVXQUAD.
Per @Joachim_Dahl in L1/2 regularized logistic regression CVXPY should also exploit Mosek 9.0’s native exponential cone capability.
If you try either of these, please report your experience (speed difference vs. CVXQUAD) here.
Thanks for you information. My problem to be solved is a multiple subcarrier power allocation issue in wireless communication area, and it involves sum-log. For now, I have compared the following
(1) CVXQUAD (m=3, k=3) + Mosek 9.0 (Running time: 701 seconds)
(2) CVXQUAD (m=3, k=3) + SDPT3 (Runing time: 813 seconds)
(3) SCP + SDPT3 (Running time: 675 seconds)
(4) SCP + Mosek 9.0 (Results turned out to be NAN)
If smaller m and k are used, the speed will be faster, but the objective value will be larger. m=3 and k=3 are just fine. I think CVXQUAD can not significantly speed up the running.
At Mosek we occasionally see that CVXQUAD generate very bad problems.So I would be careful with it.
What I have seen in other instances is that generated models are not close to being robust feasible or infeasible.
In general whenever you approximate something in finite precision arithemetic I would be extremely skeptical about the general reliability unless you have mathematical proof that it works.
Yes, I also have a instance here.
See https://drive.google.com/file/d/1LodP5yDINfLAHlIkQr0x509_ugSe3dbx/view?usp=sharing.
You can toggle the comments to switch between SCP and CVXQUAD. The results from my laptop show that SCP works well, but CXVQUAD will go to Inf, and no matter Mosek or SDPT3 is used.
Can you try increasing the values of the Pade Approximation parameters m and k from their default values of 3 and 3 to see what that does to the accuracy of the approximation and solution?
“The parameters m and k control the accuracy of the approximation” per Proposition 1 on p. 7 of https://arxiv.org/pdf/1705.00812.pdf
I changed the value to 4 and 4, and the problem can be solved. I tested on m and k before. Increasing the value of m and k from 3 and 3 will increase the precision a little bit, but will also increase the running time. So is it really necessary to use CVXQUAD?
You can try using Mosek 9.0’s native exponential cone capability.from YALMIP, CVXPY, or another interface.
I have compared the following cases on my test code, and the results are as following:
-
CVXQUAD (m=4, k=4) : 8.499 seconds
-
CVXQUAD (m=3, k=3) : 6.618 seconds
-
YALMIP: 3.354 seconds
-
SCP in CVX: 1.729 seconds
The default solver is Mosek 9.0. It seems that CVXQUAD has no advantages on speed at all. SCP in CVX is the fastest, but SCP gets the optima only in one iteration. I guess in other cases when more iterations are needed to get the optima, SCP may be slower.
Have you checked that SCP computes a correct solution and doesn’t terminate prematurely?
Yes, I have checked that. It computed a correct solution in my test, but in only one interation. In my other cases, it sometimes generates Inf results.
OK. I am asking because it’s very unusual to solve an non-trivial problem in a single iteration.