Strict inequalities are not supported (learn why)

27 views (last 30 days)
Hello everyone
I need your help please , I am student and am working in LQR control by LMI
i face probleme with inequalities , firstly i was thinking that becose the version of matlab 2020 but now i am working with 2024
  2 Comments
Walter Roberson
Walter Roberson on 25 Jun 2024
Are you talking about the fact that for various routines you can put on restrictions A*x <= b, and A*x == b, but not A*x < b ?
mahdi
mahdi on 26 Jun 2024
Thank you I solved the problem and now I have another problem
Error using eig
Input matrix contains NaN or Inf.
Error in DYNAMIC2 (line 69)
P_eigs = eig(Pfeasible);
this is my program
A1 = [0 0;0 0];%A1
A2 = [0 10*c/a;-5*c/a 0];%A2
Unrecognized function or variable 'c'.
A3 = [0 0;0 -10*c/a];%A3
A4 = [0 10*c/a;-5*c/a -10*c/a];%A4
B = [1/(a*Ra) 1/(a*Ra);L/(a*Ra) -L/(a*Ra)];%Bi
alpha = 3;
beta = 0.1;
% تعريف مصفوفات التكلفة
Q = [6 0; 0 9];
R = 1;
% حل معادلة P B R^-1 B^T P = Q يدويًا
%[P, ~, ~] = care(A, B, Q, R);
%[K,p,e] = lqr(A,B,Q,R)
%disp('Matrix P calculated using manual method:');
%disp(P)
%disp('Matrix K calculated using manual method:');
%disp (K)
%% CONTROLLER: LQR via H2 control
P = sdpvar(2,2);
Y = sdpvar(2,2);
E= 1e-6
W001 = sdpvar(2,2);
W002 = sdpvar(2,2);
W003 = sdpvar(2,2);
W004 = sdpvar(2,2);
gamma = 1;
H11 = A1*P + B*W001 + (A1*P + B*W001)' + 2*(alpha)*P;
H12 = [-Y (R^0.5)*W001; ((R^0.5)*W001)' -P];
H13 = trace((Q^0.5)*P*(Q^0.5)') + trace(Y);
H14 = A1*P + B*W001 + (A1*P + B*W001)' + 2*(beta)*P;
H21 = A2*P + B*W002 + (A2*P + B*W002)' + 2*(alpha)*P;
H22 = [-Y (R^0.5)*W002; ((R^0.5)*W002)' -P];
H23 = A2*P + B*W002 + (A2*P + B*W002)' + 2*(beta)*P;
H31 = A3*P + B*W003 + (A3*P + B*W003)' + 2*(alpha)*P;
H32 = [-Y (R^0.5)*W003; ((R^0.5)*W003)' -P];
H33 = A3*P + B*W003 + (A3*P + B*W003)' + 2*(beta)*P;
H41 = A4*P + B*W004 + (A4*P + B*W004)' + 2*(alpha)*P;
H42 = [-Y (R^0.5)*W004; ((R^0.5)*W004)' -P];
H43 = A4*P + B*W004 + (A4*P + B*W004)' + 2*(beta)*P;
F = [P>=0]+[-H11<=0]+[H12<=0]+[H13<=gamma]+[H14<=0]+[-H21<=0]+[H22<=0]+[H23<=0]+[-H31<=0]+...
[H32<=0]+[H33<=0]+[-H41<=0]+[H42<=0]+[H43<=0]...
;
ops = sdpsettings('solver','sedumi');
% ops = sdpsettings('solver','gurobi');
[opt_info] = optimize(F,[],ops);
Pfeasible = value (P);
P_eigs = eig(Pfeasible);

Sign in to comment.

Answers (1)

John D'Errico
John D'Errico on 25 Jun 2024
Edited: John D'Errico on 25 Jun 2024
It is NOT related to the release number. Sorry. That has nothing to do with it. This has been the case since release 0 of MATLAB. (To be pedantic, back then, they were called versions, not releases as I recall. And I'm not sure what the first version was, since the first one I had was either version 1 or version 3. I had them both, but I did not really start using MATLAB until version 3.)
A strict inequality, something of the general form x > a, relies on knowing ALL of the digits of a number. And the problem is, even for a number like 1/3, you cannot store that number exactly in floating point arithmetic. And worse, any computations done using floating point numbers end up having some slop in them, in the least significant bits. We can see the perfect axample here:
0.3 - 0.1 - 0.2 == -0.2 - 0.1 + 0.3
ans = logical
0
Now surely that is a mathematical equality, right? And since we are talking strict inequalities, this next one yields a true result!
0.3 - 0.1 - 0.2 > -0.2 - 0.1 + 0.3
ans = logical
1
How could that possibly be true? Another example you should consider is this one:
1 + 1e-20 > 1
ans = logical
0
Now, surely that should have be true, right? At least it must be true if a strict inequality could ever be employed in any code. In fact, as far as double precision arithmetic is concerned, we have this counter-intuitive result instead:
1 + 1e-20 == 1
ans = logical
1
Again, you cannot trust the least significant bits of a floating point number. (Well, at least not unless you fully understand everything I have written here, and far more about floats and how to work with them. And even then, don't trust the least significant bits. And since you asked this question, you are not even close to that point.)
All of this gets worse when you are working with linear algebra, where many hundreds, thousands, or millions of adds, subtracts and multiplies are performed. The point is, asking for a STRICT inequality to be recognized and enforced is impossible.
  3 Comments
John D'Errico
John D'Errico on 26 Jun 2024
This is a compeltely different question. Ask it in a new question, as otherwise, you make this question into a long random thread that just asks for gneral consulting.

Sign in to comment.

Categories

Find more on Linear Matrix Inequalities in Help Center and File Exchange

Products


Release

R2024a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!