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

[Joshua Redstone]

OK, so I spoke too soon :(.  I've found another case that breaks with octave
compiled --without_blas.
This time, I found that the qp() solution stepped outside of feasibility on
iteration 148.  However,
when I took the feasible solution from iteration 147 and reran qp() on it,
it run for another 300 iterations without violating constraints.
Is there information that is carried across iterations that changes that
could be causing problems?
Josh

On Sat, Apr 12, 2008 at 9:13 AM, Joshua Redstone <redstone at gmail.com> wrote:

> Hi Gabriele,
> I recompiled octave wth the flag --without-blas, and it works now!  I get
> a reasonable answer to the example problem.
> So my guess is that there's some problem with the osx libraries that
> octave links with.
> Josh
>
>
> On Fri, Apr 11, 2008 at 7:39 AM, Gabriele Pannocchia <
> g.pannocchia at ing.unipi.it> wrote:
>
> > Hi Josh
> >
> > > My mistake, The l2-norm of eVrH is 1.  I didn't realize Z was a matrix
> > > and so was printing too many entries of eVrH.
> >
> > Yes, Z is a matrix. Briefly (to avoid bothering people in this list with
> > linear algebra lectures...), the active set QP solver works in this way:
> > - the current active set includes ALL equality constraints plus the
> > inequality constraints that are currently active, i.e. such that the
> > inequality is actually an equality: we include these constraints in the
> > active set matrix, denoted by
> > - Z is computed as a basis for the null-space of Aact, i.e. it is a full
> > rank matrix such that Aact*Z = 0. In the __qp__.cc Z is computed with a
> > static function (at the beginning of the code) which replacates what it
> > is done by null.m. It is based on an SVD, so even each column of Z
> > should have l2-norm equal to 1.
> > - The step is computed (when info=1) as: Z*eVrH.
> >
> > Can you confirm that the columns of Z have unitary norm?
> >
> > If you compute a very small step p, you should have
> > (max_p < rtol) = true in line 304. Can you confirm?
> >
> > Gabriele
> >
> > > It's a bit hard tracking down this bug because I don't have a good
> > > idea of the math behind the code so don't know what to expect.
> >
> > I understand and the other problem is that I cannot reproduce the error
> > on my linux-i686 machine.
> > If you can, and want to understand how the code works, please have a
> > look at Chapter 16 of Nocedal and Wright "Numerical Optimization",
> > Springer-Verlag 1999. In particular, the basic algorithm is described in
> > section 16.4.
> >
> > Cheers,
> >         Gabriele
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/bug-octave/attachments/20080412/41d73f40/attachment.html