[Help-glpk] new APIs : some suggestions

[Robbie Morrison]

Hello Andrew and fellow API users

I have a few suggestions for new or reinstated GLPK
APIs.  Some were previously discussed in 2008, others
are novel.  My guess is that some would require just a
few lines of code.

The one I miss the most is 'glp_get_mat_val'.

---------------------------------
 API request : glp_get_mat_val
---------------------------------

This (proposed) call is particularly useful if the
sparse matrix vectors 'ia' 'ja' 'ar' have already been
discarded.  The current work-around is to call
'glp_get_mat_row' and hunt thru the returned
C-array for the required col.

    2.3.17+  Retrieve constraint matrix coefficient

    Synopsis

        double glp_get_mat_val(glp_prob *lp, int i, int j);

    Description

        The routine 'glp_get_mat_val' returns a_ij, the
        constraint matrix coefficient for row i and
        column j, or zero if not explicitly set.

        The routine will print a error and terminate
        execution if the row or column index is out of
        range.

        This routine is useful if the sparse matrix
        vectors 'ia', 'ja', and 'ar' are no longer
        current or have already been discarded.

---------------------------------
 API request : glp_set_obj
               glp_get_obj
---------------------------------

The following (currently hypothetical) API pair would
have been useful in my application program:

    2.2.11+  Set (replace) objective function

    Synopsis

        void glp_set_obj(glp_prob *lp, int len,
               const int ind[], const double coef[]);

    Description

        The routine 'glp_set_obj' stores (replaces)
        the contents of the objective function of the
        specified problem object.

        The column indices and numerical values of
        new objective coefficients must be placed in
        locations 'ind[1], ..., ind[len]' and
        'coef[1], ..., coef[len]', respectively,
        where 0 <= 'len' <= 'n' is the new length of
        the objective function and 'n' is the current
        number of columns in the problem object.
        Elements with identical column indices are not
        allowed.  Zero elements are allowed but they are
        not stored.  If the parameter 'len' is 0,
        then 'ind' and/or 'coef' can be specified as NULL.

        The existing objective function name, if set,
        remains unchanged.

    2.3.14+  Retrieve objective function

    Synopsis

        int glp_get_obj(glp_prob *lp, int len,
               int ind[], double coef[]);

    Description

        <not written>

---------------------------------
 API request : class functions
---------------------------------

My application program used to call the following, now
retired, APIs:

    int  lpx_get_class(LPX *lp)  /* returns class */
    void lpx_set_class(LPX *lp, int class)
    class in { LPX_LP, LPX_MIP }

These are no longer documented in the manual -- and I
have duly removed them from my code as recommended.

However I found the 'lpx_get_class' function generally
helpful and occasionally used the 'lpx_set_class'
function during testing in the past.  I guess one can
duplicate the get function as follows (and also develop
more resolved versions):

    if ( glp_get_num_int(lp) == 0 )
        // problem is LP
    else
        // problem is some form of MIP

In any case, the following (currently hypothetical)
APIs could still be useful (the 1 indicates 0-1
programming):

   int  glp_get_class(glp_prob *lp)
   void glp_set_class(glp_prob *lp, int class)
   class in { GLP_LP, GLP_MIP, GLP_M1P, GLP_IP, GLP_1P, ... }

Moreover I presume the 'lpx_set_class(, LPX_LP)'
routine simply marked the problem object as "LP" so
that the original formulation could be trivially
reinstated with a second toggled call.

Alternatively, there may be good reason for the removal
of these APIs.  And perhaps there is an equally good
work-around for the 'set' function?

---------------------------------
 API request : glp_empty_prob
---------------------------------

First note that this proposed routine is somewhat
different from 'glp_erase_problem'.

I currently empty my problem (before rebuilding a
reasonably similar problem again) by calling
'glp_del_rows' and 'glp_del_cols'.  However these two
routines require me to suitable generate C array
sequences in advance.

Hence, the following (currently hypothetical) API might
be useful:

    void glp_empty_prob(glp_prob *lp)

This API would remove all problem creation data
supplied by the client code, but retain as much
internal information as is sensible and/or useful.

---------------------------------
 API request : glp_init_env
---------------------------------

My application program makes a call to
'glp_term_out(GLP_OFF)' on start-up if the --silent
command-line option has been set.  However this call is
only legal if a problem object has already been created
-- although it need not persist.

Hence, the following (currently hypothetical) API might
be useful:

    int glp_init_env()  /* returns zero on success */

This API can then be called before any of the various
library environment routines in cases where a GLPK
problem object has not been created or where the
situation is unclear.  Or, alternatively, have these
library environment routines initiate the environment
automatically as required (perhaps the better
approach).

---------------------------------
 API request : glp_combine
---------------------------------

This last suggestion is speculative but could work at
various levels -- at its simplest, it could just
transfer the current problem creation data from 'lp2'
to 'lp'.

    void glp_combine(lp, lp2)  /* lp2 is added to lp */

At present, I don't need this API (although I did
strongly consider generating multiple 'glp_prob's and
combining them in some way before attempting the
optimization).

---

Apologies for the long posting.  Hope these suggestions
are of interest.  I would be more than happy to modify
the 'doc/glpk*.tex' files as required, test the new
APIs, and note the changes on the GLPK wikibook.

Finally, many thanks for this excellent library which
fits my needs perfectly -- including the C-based APIs,
the GNU gcc compiler support, and, of course, the GPL
licensing.

with best wishes
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from IMAP client]