octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

help in modifying __qp__.cc


From: John W. Eaton
Subject: help in modifying __qp__.cc
Date: Mon, 03 Nov 2008 11:12:34 -0500

I'm moving this discussion to the mailing list to see if anyone has
comments or would like to help out with making a change like I'm
proposing below.

Thanks,

jwe


On 30-Oct-2008, John W. Eaton wrote:

| On 30-Oct-2008, Gabriele Pannocchia wrote:
| 
| | Hi John,
| | 
| | after discussing with Steve Wright about the problem of redundant active
| | constraints (i.e. rank deficient active set matrix) that is not
| | correctly handled in the current __qp__.cc, I am ready to make a change
| | which, I think, could improve the robustness of the algorithm
| | significantly.
| | 
| | The change requires to solve a linear program for computing the Lagrange
| | multipliers when the current Aact is not full rank.
| | 
| | Could you please give me some tips on how I can make a "direct" (i.e.
| | without feval) call to glpk to solve a problem like:
| | 
| | min c'*x s.t. C*x=d, D*x<=d 
| | 
| | or in the LP standard form. 
| | 
| | min c'*x s.t. C*x=d, x>=0
| 
| I'm not an expert in using glpk.  I did not write the interface to it
| for Octave.  The example in the Octave sources of using glpk directly
| is in src/DLD-FUNCTIONS/__glpk__.cc in the Octave sources.  If you add
| direct calls to glpk in __qp__.cc, then we will also need to modify
| src/Makefile.in so that it links __qp__.o with the glpk library when
| it creates __qp__.oct.

After giving this some more thought and looking at the __glpk__.cc
file, it might be best to create another level of abstraction that we
can add to liboctave.  At the very least, it would probably be good to
have a function like

  ColumnVector
  glpk (const ColumnVector& c, const Matrix& C, const ColumnVector& d,
        const glpk_options& opt);

and probably also

  ColumnVector
  glpk (const ColumnVector& c, const SparseMatrix& C, const ColumnVector& d,
        const glpk_options& opt);

to solve the standard problem as you've stated it above.  The
glpk_options argument would be a class.

We probably also need a way to detect errors/return an error code.

Most of the work is done already in __glpk__.cc, but it would be much
easier for you to use glpk in __qp__.cc if you could call functions
with this interface.

Perhaps we should discuss this on the maintainers list.  Someone else
might be interested in helping out with this job.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]