forum.alglib.net

I am trying to implement a simple minimisation under a quadratic inequality constraint and a linear equality constraint as well as lower and upper bounds. My problem is as follow:

min: x1*(-0.00498) + x2*0.05656

u.c. :

. x1^2 * 0.00001048 + 2*x1*x2*0.001431 + x2^2*0.6737996 <= 0.0084050
. x1 + x2 = 1.0
. 0 < x1 < 0.9
. 0 < x2 < 0.9

Once implemented in F# using Alglib it seems that the constraints are not respected. Neither the sum x1+x2 is equal to 1.0 nor the variance is below 0.0084. Though lower and upper bound are respected, my objective function with x2 is improved (lower) than with x0. I believe I have an issue with my formulation of the constraints, but I can't see which one.



let nsfunc2_jac(x:float[]) (fi:float[])(jac:float[,])=
fi.[0] <- -(x.[0]*-0.00498+x.[1]*0.05656)
fi.[2] <- x.[0]+x.[1]+x.[2]-1.0
fi.[1] <- x.[0]*x.[0]*0.00001048 + 2.0*x.[0]+x.[1]*0.001431 + x.[1]*x.[1]*0.6737996-0.0084050
jac.[0,0] <- -0.00498
jac.[0,1] <- 0.05656
jac.[2,0] <- 1.0
jac.[2,1] <- 1.0
jac.[1,0] <- 2*x.[0]*0.00001048 + 2*x[1]*0.001431
jac.[1,1] <- 2*x.[0]*0.001431 + 2+x[1]*0.6737996

let mutable state2 = new alglib.minnlcstate()
let mutable rep2 = new alglib.minnlcreport()
let mutable nrep = new alglib.ndimesional_rep(func2)
let x0 = [|0.8999, 0.1001|]
alglib.minnlccreate(2,x0, &state2)
alglib.minnlcsetalgoaul(state2, 1000.0, 15.0)
alglib.minnlsetcond(state2, 0.000001,10.0)
alglib.minnlcsetscale(state2, [|1.0,1.0|])
alglib.minnlcsetprecexactlowrank(state2, 5.0)
alglib.minnlcsetnlc(state2, 1,1)
alglib.minnlcsetbc(state2, [|0.0,0.0|], [|0.9,0.9|])

alglib.minnlcoptimize(state2, jac, nrep, None)
let x2, rep = alglib.minnlcresults(state2)
let var = x2.[0]*x2.[0]*0.00001048 + 2.0*x2.[0]+x2.[1]*0.001431 + x2.[1]*x2.[1]*0.6737996
printfn "Variance: %s" var.ToString()
I get Var = 0.53 well above the 0.0084050 target. In fact, after the first iteration both my equality and my inequality constraints are broken and the algorithm never comes back within the range.

More worisome, I receive an answer TerminationType = 1 -> OK

Hello, it looks like that even with the latest version of Alglib the solution can still be outside the boundaries with a positive termination output.
Do you have any idea why it happens?

Do you have any concrete example, and which exactly solver (AUL2, SQP) do you use?

The original example has a mistake in Jacobian

Hi Sergey,
I can't share my code because it involves many classes, so I have tried to replicate a simpler function that returns more or less the same issue:



This will be the output:



As you see, the second non linear condition is not respected, but the termination type is 2.
Mine code has similar outputs, except termintation type that is 7.

Hi!

1. The problem with constraints, especially nonlinear ones, is that in real life it is impossible to tell whether they are satisfied or not. E.g., equality constraints are ALWAYS violated, the question is how big is the violation. In your case it is obviously a large violation (9.18), but what about 0.002 - is it big enough to trigger the alarm?

Our present approach is that we do not decide whether violation is large or small, we simply return all the information about the solution and let the caller decide whether it is bad or good. It is possible to do differently, but presently we prefer to give no promises... because any such promise will become a part of API.

2. Speaking of your specific demo, targets/constraints involving periodic functions like sin() and cos() are really difficult to handle. You need a good initial point in order to be able to converge to the solution. In your case the solver stuck in a local minimum of feasibility error.

Probably, something like that happens in your 'real' problem.

Sergei

Hi Sergey,

thanks for the explanation!

One more thing: in the manual the termination type 7 is described as



Could you give more details on the meaning?

The exact meaning is solver-dependent. The SQP solver typically returns it when the target stagnated (changes really slowly) for too long, or when the stopping tolerances are too tight, i.e. less than sqrt(machineEpsilon). Other solvers have slightly different conditions, but generally it triggers when the stopping tolerances are too tight and progress is too slow.