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

[Olaf Till]

On Fri, May 22, 2015 at 04:28:52PM +0100, Asma Afzal wrote:
> > 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.

You misunderstand me. With 'specified', I mean 'explicitely stated',
e.g. in the user documentation. What you mean is that the order is
determined by the code. That is true, but the code and so the order
can be changed. If there is a formal explicit specification of the
order, developers are more or less bound to it.

> > 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.

Well, if we know how qp.m orders the input with respect to the
returned lambda (and if this order is formally specified so that it
won't change in the future), could we not principally use this
knowledge to extract the correct parts of the lambda returned by qp.m?

Olaf

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

signature.asc
Description: Digital signature