[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