Re: fmincon wrapping nonlin_min

[Olaf Till]

On Wed, Jul 15, 2015 at 08:12:19PM +0100, Asma Afzal wrote:
> Hi Olaf,
> 
> > You can probably test this in the original fmincon by printing the
> > parameter argument and the returned values in the function for
> > non-linear equalitiy constraints (and maybe you can even set an option
> > to indicate the starts of itereations?). If the returned values for
> > non-linear equality constraints assume the value zero several times
> > before the final function calls, this indicates it's a feasible path
> > algorithm. If they get zero only in the last function calls, it's
> > probably different.
> 
> I ran a simple example with non-linear inequality constraints in Matlab:
> 
> objective_function = @ (p) p(1) ^ 2 + p(2) ^ 2;
> pin = [-2; 5];
> c = @(p) [];
> ceq = @ (p) p(1)^2 + 1 - p(2);
> nonlcon = @(p) deal (c (p), ceq (p));
> opts = optimset('Display', 'iter-detailed', 'Algorithm', 'interior-point')
> [p, objf, cvg, outp] = fmincon (objective_function,
> pin,[],[],[],[],[],[],nonlcon,opts)
> 
> *Interior-point:*
>                                                                First-order
>      Norm of
>  Iter   F-count            f(x)        Feasibility      optimality
> step
>     0       3   2.900000e+001   0.000e+000   1.035e+001
>     1       7   5.294118e-001   1.675e+000   9.135e-001   5.336e+000
>     2      10   1.687652e-001   1.234e+000   6.270e-001   1.116e+000
>     3      13   4.490516e-001   8.854e-001   1.929e+000   1.053e+000
>     4      16   3.751190e-001   4.062e-001   4.206e-001   6.686e-001
>     5      19   9.635641e-001   2.150e-002   2.611e-001   4.041e-001
>     6      22   9.939794e-001   3.202e-003   6.628e-002   5.890e-002
>     7      25   9.997458e-001   1.272e-004   7.593e-004   1.166e-002
>     8      28   1.000000e+000   1.618e-008   1.266e-005   1.798e-004
>     9      31   1.000000e+000   3.791e-013   1.043e-007   6.075e-007
> 
> Optimization completed: The relative first-order optimality measure,
> 5.215406e-008,
> is less than options.TolFun = 1.000000e-006, and the relative maximum
> constraint
> violation, 3.791412e-013, is less than options.TolCon = 1.000000e-006.
> 
> Optimization Metric                                         Options
> relative first-order optimality =  5.22e-008       TolFun =  1e-006
> (default)
> relative max(constraint violation) =  3.79e-013    TolCon =  1e-006
> (default)
> 
> *Active-set:*
>                                       Max       Line search  Directional
>  First-order
>  Iter F-count    f(x)        constraint   steplength   derivative
> optimality
>     0      3           29            0
> 
>     1      7     0.529412        1.675          0.5        -10.7
> 1.91
>     2     10      0.14227        1.171            1        -1.45
>  0.928
>     3     13     0.500415       0.8574            1       -0.696
> 1.78
>     4     17    0.0417358       0.9877          0.5        -1.39
>  0.674
>     5     22    0.0504856       0.8697         0.25       -0.351
> 1.06
>     6     30     0.139937       0.8609       0.0313        0.431
> 5.11
>     7     33     0.648881       0.2892            1      -0.0962
> 8.02
>     8     36      1.07827     0.004895            1         1.36
> 1.03
>     9     39      1.01786     0.005358            1       -0.872
>  0.558
>    10     42     0.979533      0.01031            1       -0.476
> 0.0237
>    11     45     0.999968   1.623e-005            1         1.84
> 0.000963
>    12     48            1       2.442e-009            1        0.624
>  3.36e-006
> 
> Optimization stopped because the norm of the current search direction,
> 5.599703e-007,
> is less than 2*options.TolX = 1.000000e-006, and the maximum constraint
> violation, 2.441955e-009, is less than options.TolCon = 1.000000e-006.
> 
> Optimization Metric                                               Options
> norm(search direction) =  5.60e-007                        TolX =  1e-006
> (default)
> max(constraint violation)  =  2.44e-009                  TolCon =  1e-006
> (default)
> 
> *Sqp:*
> 
> 
>    Norm of       First-order
>  Iter    F-count         f(x)         Feasibility  Steplength        step
>      optimality
>     0       3   2.900000e+001  0.000e+000  1.000e+000  0.000e+000
>  1.100e+001
>     1       7   5.084706e+000  3.282e+000  7.000e-001  7.470e+000
>  3.947e+000
>     2      10   9.892848e-001  8.048e-001  1.000e+000  3.078e+000
>  1.942e+000
>     3      13   1.683993e-001  5.991e-001  1.000e+000  8.274e-001
>  6.326e-001
>     4      16   9.968958e-001  2.108e-003  1.000e+000  5.949e-001
>  5.552e-001
>     5      21   9.965201e-001  1.856e-003  4.900e-001  2.795e-002
>  2.770e-001
>     6      24   9.998171e-001  9.269e-005  1.000e+000  9.774e-003
>  5.397e-003
>     7      27   9.999984e-001  8.099e-007  1.000e+000  9.046e-004
>  1.038e-005
>     8      30   1.000000e+000  1.560e-013  1.000e+000  8.981e-007
>  8.941e-008
> 
> Optimization completed: The relative first-order optimality measure,
> 4.470348e-008,
> is less than options.TolFun = 1.000000e-006, and the relative maximum
> constraint
> violation, 1.559863e-013, is less than options.TolCon = 1.000000e-006.
> 
> Optimization Metric                                         Options
> relative first-order optimality =  4.47e-008       TolFun =  1e-006
> (default)
> relative max(constraint violation) =  1.56e-013    TolCon =  1e-006
> (default)
> 
> For all the algorithms, the feasibility (constraint function) column meets
> the TolCon specification in the final few iterations so does this indicate
> a feasible path algorithm?

No, because the non-linear constraints are not satisfied after each
step. These algorithms rather seem similar to Octaves sqp with respect
to this. 'lm_feasible' does it differently.

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature