qp() in Octave 3.0.0 returns result egregiously violating input constraints

[Joshua Redstone]

Hi Gabriele,
Yes, feasibility is lost during the iterations, at iteration 187 for me, and
Ben observed it reporting infeasible solutions at iteration 200.
It seems to be particular to the intel osx machines.
I think we're still not sure where the problem lies.
Thanks,
Josh

On Sun, Apr 6, 2008 at 11:46 AM, Gabriele Pannocchia <
g.pannocchia at ing.unipi.it> wrote:

> > In any case, we know for the example problem that feasible solutions
> > exist, so according to the current spec for qp() it must return one of
> > them, even if it's not the global optimum.  One could change the spec
> > to say it may not return feasible solutions, but it's probably
> > better/easier to find the root problem - I hope.
>
> qp() must return only feasible solutions or INFO.info = 6, i.e. no
> feasible solution exists. Just to sketch how it works:
> 1) If an initial point is provided and it is feasible, go to 3.
> Otherwise,
> 2) Call glpk to solve an LP that tells us either there is no feasible
> solution or a feasible starting point.
> 3) The iterations start and at each iteration the current X remains
> feasible because it is in the form:
>        x(k) = x(k-1) + Z_k*p
> where Z_k is a basis matrix for the null space of the active constraints
> (i.e. equality constraints and inequality constraints currently active).
> If a new constraint becomes active it is inserted into the active set
> matrix...
>
> If feasibility is lost during the iterations, then there is a bug. It is
> my understanding from previous messages that it is not strictly related
> to qp.m and __qp__.cc but to linear algebra libraries.
> Most likely it is related to the computation of the null space of the
> active set matrix.
>
> However, please let me know if you feel that something should be done in
> qp.m or __qp__.cc.
>
> Gabriele
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/bug-octave/attachments/20080406/18f36593/attachment.html