The return value in the process of cvx is Incorrect

    cvx_begin
    cvx_solver sedumi
    variable px(1,2)
    rate1=log(1+px(1,1)*h1/z)/log(2);

    rate2=log((px(1,1)+px(1,2))*h2+z)/log(2);  # there is something wrong

    rate=rate1+rate2-( log(p1*h2+z)/log(2)+ [h2/((p1*h2+z)*log(2)),0] *( [px(1,1),px(1,2)] -[p1,p2] )' );
    c=(r1+r2)*t*w*rate;
    maximize (c)
    subject to
    px(:)<=pnomamax
    rate1>=speedr
    px(:)>=0
    cvx_end

In this function,I return the value of rate2 and px.
h2 ,z are fixed.
but I calculate “log((px(1,1)+px(1,2))*h2+z)/log(2)”, it is not equal to the rate2…
did i have some mistakes or it is a bug?
thank you for your help

There is no guarantee, or “expectation”, that the value of a CVX expression after CVX execution completes will be the value of that expression at the optimal value of the CVX variables. Therefore, if you want to know such value, you should compute it using the optimal value of the CVX variables after CVX execution completes.

This is not a bug, it’s a feature. You have assumed something which is not stated in the CVX Users’ Guide. Perhaps the CVX Users’ Guide could make this point explicitly.

Edit: See Abnormal result of lambda_max function

Thank you for your patient reply.
So do you mean the value of variables that i return maybe not the optimal one?how can I get the optimal variables.
The final result of the object function “c” which I use the “px” that I returned to compute is not equal to the result of cvx optimal_value .
Thank you your further explanation again .

Compute c using only the optimal value of px. It should equal cvx_optval (within roundoff) if CVX claims the problem was solved to optimality. px should have the optimal value. rate1, rate2, rate, and (perhaps?) even c might not, unless you compute them starting from px.

In summary, the CVX variables (in your case, px) and cvx_optval should be the optimal values when CVX execution ends with declaration of optmality. Anything else (CVX expressions) might not correspond to optimal values.

Yes that is the problem i got.in my case. The cvx-optval should be “c” because it only use one variable px.I use px to compute c and i got a different result with the cvx-optival,and cvx claims that the problem was solved.
rate2 is part of c. I thought this was problem.
Actually rate1 is the same with the result that i use px to compute,while rate2 is not.
and if i use the px to compute c,i will got the right magnitude.while the cvx_optival i got seems too big.
How do i deal with it?
Thank you again for your patience.

I find your description to be unclear. Please provide the output from running CVX, and all the MATLAB calculations and displays of variable values you are performing after CVX execution. Please provide comments describing any values or results you do not think are correct.

Ok,but I don’t have my pc with me now , I will provide it tomorrow

Sorry for the unclear description.

I use the optimal variable “px” which cvx give me to recompute my object function with exactly the same formula and parameters . but the result is not equal to the cvx_optimal.

Here is the whole code for test.Each parameter is fixed and only one variable “px”.

n=2;    
su=rand(1,n);
disu=sqrt(su)*0.5;
hu0=128.1+37.6*log10(disu)+exp(randn(size(disu)));
hu=10.^(-hu0/10);
h=sort(hu);        
t=10e-4;
w=15000000;%HZ
zd=3.98e-19;
z=zd*w;
pnomamax=250;
speedr=500/15000;
[ro,po,h,cvx_optval,p]=cvx_oma(2,250,250,h,500/15000);
r=(sum(ro,2))';

p1=250;p2=250;
h1=h(1,1);h2=h(1,2);
r1=r(1,1); r2=r(1,2);%parameters

    cvx_begin
    cvx_solver sedumi
    variable px(1,2)
    rate1=log(1+px(1,1)*h1/z)/log(2);
    rate2=log((px(1,1)+px(1,2))*h2+z)/log(2);
    rate=rate1+rate2-( log(p1*h2+z)/log(2)+ [h2/((p1*h2+z)*log(2)),0] *( [px(1,1),px(1,2)] -[p1,p2] )' );      
    ratest=rate2-( log(p1*h2+z)/log(2)+ [h2/((p1*h2+z)*log(2)),0] *( [px(1,1),px(1,2)] -[p1,p2] )' );        
    c=(r1+r2)*t*w*rate;
    
    compute=(r1+r2)*t*w*( log(1+px(1,1)*h1/z)/log(2) +  log((px(1,1)+px(1,2))*h2+z)/log(2) -( log(p1*h2+z)/log(2)+ [h2/((p1*h2+z)*log(2)),0] *( [px(1,1),px(1,2)] -[p1,p2] )' ));
    
    maximize (compute)
    subject to
    px(:)<=pnomamax
    rate1>=speedr
    ratest>=speedr
    px(:)>=0
    cvx_end
    
    recompute=(r1+r2)*t*w*( log(1+px(1,1)*h1/z)/log(2) +  log((px(1,1)+px(1,2))*h2+z)/log(2) -( log(p1*h2+z)/log(2)+ [h2/((p1*h2+z)*log(2)),0] *( [px(1,1),px(1,2)] -[p1,p2] )' ));

thank you for your help;

You haven’t provided a reproducible example. cvx_oma is used but not provided. If you could choose a specific instantiation of random numbers (rand and randn), and read in (assign) the values as ASCII, then your exact problem should be reproducible.

What is the result of cvx_version? CvX 3.0beta is known to still have a number of bugs, discovered and undiscovered.

Just as a semi-random thought, your z = 5.9700e-12, which I would not rule out as possibly contributing to numerical difficulties (instability). I don’t know whether that is causing part or all of the discrepancy here or not. Can you try re-running with numbers which are all closer in magnitude to 1 and see what happens?

My fault,i forgot that cvx_oma.。and my cvx version is 2.1
Now I picked a specific set of numbers. It should be reproducible now…and it is still different between cvx_optimal and the “recompute”.
Then i set all of them as 1 , it works cvx_optimal and “recompute” are equal…Actually,just set all the numbers which has e in it,in this case ,is “t”,“z” and "h"
but i don’t get it,Is z = 5.9700e-12 a semi-random expression or something?How do I deal with these numbers.
And I get some parameters from other functions,need i reform them?

n=2;    
t=10e-4;
w=15000000;
z=5.9700e-12;
pnomamax=250;
speedr=500/15000;
% r=[0.00559072788641364,0.994409272111680];
% h=[1.46497117115015e-12,3.01110743301851e-12];   
r=[0.5,0.5];
h=[1.5e-12,3e-12];


% t=1;
% w=1;
% z=1;
% h=[1,1];
% r=[1,1];



p1=250;p2=250;
h1=h(1,1);h2=h(1,2);
r1=r(1,1); r2=r(1,2);%parameters

cvx_begin
cvx_solver sedumi
variable px(1,2)
rate1=log(1+px(1,1)*h1/z)/log(2);
rate2=log((px(1,1)+px(1,2))*h2+z)/log(2);
rate=rate1+rate2-( log(p1*h2+z)/log(2)+ [h2/((p1*h2+z)*log(2)),0] *( [px(1,1),px(1,2)] -[p1,p2] )' );      
ratest=rate2-( log(p1*h2+z)/log(2)+ [h2/((p1*h2+z)*log(2)),0] *( [px(1,1),px(1,2)] -[p1,p2] )' );        
c=(r1+r2)*t*w*rate;

compute=(r1+r2)*t*w*( log(1+px(1,1)*h1/z)/log(2) +  log((px(1,1)+px(1,2))*h2+z)/log(2) -( log(p1*h2+z)/log(2)+ [h2/((p1*h2+z)*log(2)),0] *( [px(1,1),px(1,2)] -[p1,p2] )' ));

maximize (compute)
subject to
px(:)<=pnomamax
rate1>=speedr
ratest>=speedr
px(:)>=0
cvx_end

recompute=(r1+r2)*t*w*( log(1+px(1,1)*h1/z)/log(2) +  log((px(1,1)+px(1,2))*h2+z)/log(2) -( log(p1*h2+z)/log(2)+ [h2/((p1*h2+z)*log(2)),0] *( [px(1,1),px(1,2)] -[p1,p2] )' ));

I think your problem is numerically ill-behaved. I failed to solve the problem using CVX 3.0beta with sedumi and sdpt3, and scs and ecos failed to converge within the default number of iterations.

Using CVX 2.1, I got different solutions using sedumi and sdpt3.

Using sdpt3:

> Status: Solved
> Optimal value (cvx_optval): +104851
>  
> recompute =
>      1.048514219308144e+05

> px =
>    1.0e+02 *
>    2.499999999550095   2.499999999513760

Using sedumi:

Status: Solved
Optimal value (cvx_optval): +245130
 
recompute =
     9.722111479447575e+04

px =
   1.0e+02 *
   2.263528487572896   1.258613598436239

I will have to defer to others to further investigate, but numbers such as 1.5e-12, 3e-12, 9.5e-12 inside the log may be causing difficulties. Perhaps you can manipulate the logs to get a numerically nicer formula for the objective function.

Thank you for your help.
I thought this function is concave.and it that situation means maybe it is not?
or just there is some trouble with cvx to deal with the log which has 1.5e-12, in it and i just use sdpt3 to solve my problem.

CVX has accepted your problem as “convex” (concave objective being maximized subject to convex constraints), but there appear to be numerical difficulties in the solution. I wouldn’t trust either sdpt3 or sedumi in this case. I have to defer to others for a more definitive assessment or help.

Yeah, those small values in the 10^{-12} range are likely causing problems. The solvers are likely treating them as “effectively” zero.