Re: RFC: quadprog/lsqlin with __qp__ (Re: GSoC 2015, optim)

[Asma Afzal]

Hello,

> Only read lines 460 to 477 for now, but I'm pretty sure that the
> number of _active_ conastraints is only important internally to
> __qp__, to fill in the returned lambda. The length of the returned
> lambda does not seem to depend on how many of the inequality
> constraints are active, for inactive constraints the elements of
> lambda remain zero. So your first statement (before the parantheses)
> on the length should be true.

The length of lambda is the equal to the total number of constraints
provided to __qp__. True.
line 462 [1]: lambda.resize (n_tot).
The order of constraints is changed when the blocking constraint (not
previously included in the active constraints) is added (line 434-436)
but the re-ordering is taken care of in lines 471-475 putting the
multipliers in their respective places (count kept by the vector
Wact).

> RFC:
>
> The problem with wrapping qp.m is that this order (e.g. the position
> of the bounds constraints within the inequality constraints) is not
> specified by qp.m

It is, isn't it? (lines 214-217, 223-226, 229-248 [2]) The constraints
are always placed in the order (lower bounds;upper bounds; inequality)
The bounds are not included within the inequality constraints when
they are Inf or are too close making an equality constraint instead.

> and principally might change; also, as you
> mentioned, qp.m seems to strip INF constraints before calling __qp__
> but does not process the lambda (returned by __qp__) accordingly, and
> this behaviour is also not specified and might change. So it could be
> better to wrap __qp__ directly than considering how qp.m processes the
> constraints.
> On the other hand, __qp__ also does not specify whether equality or
> inequality constraints come first in lambda,

It does. The active constraints matrix Aact (and similarly bact) has
equality constraints on top and in order and then it updates the lower
rows based on active/blocking inequality constraints (Line 115-117
[1]). This order is ensured in the lines 460 onward for computing
lambda.

> and __qp__ is an internal
> function of Octave, potentially subject to interface changes without
> notice. So one could argue that it would be safer to first change qp.m
> (re-suppling zeros to lambda where INF constraints were stripped,
> specifying the order within lambda in the documentation) and then to
> wrap qp.m, not __qp__. But my influence on what is in qp.m is very
> limited.
> Maybe someone else has comments on this. A possibility is that either
> you or me supplies a patch to qp.m, and the further 'strategy' is
> decided depending on whether the patch will be applied in time or not.

If a patch is submitted to qp.m to add zeros in lambda in the correct
places corresponding to Inf constraints, wrapping __qp__ still seems
necessary to compute the lengths of input arguments etc. to put the
values in the respective fields of the structure.
>
> PS: We'd better mark different larger subtopics with different
> 'Subject:' lines (done for this).

Noted.

Kind Regards,
Asma.