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

[Olaf Till]

Hi Asma,

On Fri, Jul 24, 2015 at 12:53:29PM +0100, Asma Afzal wrote:
> ...
> I spent some time to dig into __qp__.cc, but it turns out that the
> bound constraints are places alternatively in qp.m (lines 287-288)
> [1]. 
> ...
> So I changed this in the updated code in [2].  For the sign of
> lambda.eqlin, it is always the case for all the examples I tried so
> I'm just using -1* lambda.eqlin for now.

see below.

> Few more things that affect the ordering of lambda:
> 
> - Too close bound constraints:
> qp treats it as an equality constraint and hence the resulting
> Lagrange multiplier is placed next to the multipliers corresponding to
> the equality constraints in lambda generated by qp.
> In Matlab, the resulting multiplier is placed in the lambda.upper
> field while a zero is placed in the respective position in
> lambda.lower.
> ...
> - -Inf bound constraints:
> qp.m strips off the -Inf constraints before passing them to __qp__. I
> am doing the same in quadprog. I have added further checks to make
> sure the multipliers are placed in the right positions in their
> respective fields.

- Lambda should be inherently non-negative. Don't change it's sign to
  get the same value as Matlab. I don't know why they return a
  negative value.

- AFAICS the lambda is just an internal value of the algorithm, I
  actually can't see a use in returning it to the user at all (which I
  already hinted). But it never was my decision how far you should go
  with similarity to Matlab. At the least, one should stay aware that
  the values of the elements of lambda are principally
  algorithm-dependent.

- If you want to control the ordering of lambda, of course you have to
  keep track of everything your code does which effects the ordering
  of constraints, and reverse these effects in the lambda returned by
  __qp__. I trust you will do this right.

- You've seemingly decided to use a copy of qp.m, with minimal
  changes. I didn't expect this, but OTOH I've no arguments against
  this way now ...

(- The advantage of directly wrapping __qp__ was not only in
   controlling the ordering of lambda, but in being able to switch
   between backends (if other backends than __qp__ should get
   available).)

Regards,

Olaf

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

signature.asc
Description: Digital signature