Constraint set to be a real number

I am using the fmincon for optimization. In the given problem one of the constraint should be strictly a real number. I did set the costraint as such

function [c,ceq] = constraint_cost(x)
% x = [0.69996     0.42986        0.14];
.
..
A_v(i,1) = AA(i,1) * r_e(i,1)^2 * n_tot(i,1) * n_e(i,1) * n_ion(i,1) * ((Z_e(i,1)* Z_ion(i,1))/Z) * p_e(i,1) * p_ion(i,1);
end
AV_constraint_1 = isreal(A_v);
AV_constraint_2 = isnan(A_v);
c(1) = double(AV_constraint_1);
c(2) = double(AV_constraint_2);
ceq =[];
c =[c(1) c(2)];

and in the main script I use this

A = [];
b = [];
Aeq =[];
beq = [];
c =[1 0];
lb = [0.02 0.02 0.14 ];
ub = [1 0.8 0.7];
equality =@constraint_cost;

I want the c = [] to be strictly [1 0] which implies A_v is a real number. And the following didnt work for me. Is there another way to implement this ?

[Walter Roberson]

c =[c(1) c(2)] - [1 0];

possibly ?

[neil vaz]

This is giving me the same optimum with A_v being a complex number as such 146221.404490870 - 9.62183797514181e-07i

Answer 1

[John D'Errico]

First, constraints like:

AV_constraint_1 = isreal(A_v);

are not differentiable. Sorry. They can't be used in fmincon. Well, you can have them. But fmincon does not understand how to work with them, the result being failures happening that you won't understand.

And even if you set a constraint that the imaginary part of a variable be zero, you will still have a problem, since a tool like fmincon has a constraint tolerance. The constraint can fail by the constraint tolerance, and you can't use a constraint tolerance of zero. The result will still be tiny imaginary parts. Tiny, but non-zero.

Instead, use tools like nthroot, which can help you avoid generating imaginary result. Learn there the complex numbers are arising, and prevent them from happening in the first place, by using tools to prevent them.

Next, if you can learn where those pesky imaginary parts arise, then you can implement a better constraint set. For example, if you are taking the log of a number that is cometimes negative, then figure out where the negative numbers arise, and NOW you can set an intelligent constraint, on the input to the log, and NOT effectively on the result of that log.

Do you see, that you are trying to constrain the wrong thing?

Answer 2

[Steven Lord]

The outputs from the nonlinear constraint function should not be boolean values. They should be continuous values.

Try making your nonlinear constraint function return imag(A_v) as the ceq output. This will try to satisfy the constraint that imag(A_v) == 0 which would require A_v to be real (or I believe have an imaginary part smaller than the constraint tolerance.)

[neil vaz]

I did this function [ceq] = constraint_cost(x)

...

ceq = imag(A_v);

and the error is

Error using constraint_cost

Too many output arguments.

Caused by:

Failure in initial nonlinear constraint function evaluation. FMINCON cannot continue.

[Walter Roberson]

You must use

function [c,ceq] = constraint_cost(x)

If appropriate you can set

c = [];