Re: [Help-glpk] new APIs : some suggestions

[Robbie Morrison]

Hello Andrew

Many thanks for considering my suggestions.  Some
comments follow.

------------------------------------------------------------
To:          Robbie Morrison <address@hidden>
Subject:     Re: [Help-glpk] new APIs : some suggestions
Message-ID: <address@hidden>
From:        Andrew Makhorin <address@hidden>
Date:        Fri, 22 Apr 2011 20:02:44 +0400
------------------------------------------------------------

>> 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.
>
> Thank you for your suggestions.
>
> Based on the suggestions I think to add the following
> api routines:
>
> glp_get_aij (glp_get_mat_val renamed) to retrieve a
> single constraint coefficient (an element of the
> constraint matrix);
>
> glp_set_aij (for symmetry);

Sounds good!  Your new names are definitely better.

> glp_set_obj_row / glp_get_obj_row (glp_set_obj /
> glp_get_obj renamed); similar to glp_set_mat_row /
> glp_set_mat_col.

Again good.

> Glp_get_class / glp_set_class are quite unclear. The
> point is that the problem class mainly depends on the
> solver used, not on problem data.  For example, if you
> call glp_simplex, you solve lp even if some variables
> are marked as integer.

I would have thought that linear, integer, 0-1,
mixed-integer, and so on, were fundamentally attributes
of the problem and not dependent on the type of solver
(to be) applied.  Is that not so?

A similar functionality did exist with 'lpx_get_class'
and friends.  I now do this on the client-side (in C++)
as follows:

  enum ProblemKlass                // LPX_LP, LPX_MIP, 'lpx_get_class' no
longer supported
    {
      prob_not_specified   = 0,
      prob_linear          = 1,    // GLP_CV
      prob_mixed_integer   = 2,    // GLP_CV + GLP_IV (+ GLP_BV optionally)
      prob_mixed_zero_one  = 3,    // GLP_CV           + GLP_BV
      prob_pure_integer    = 4,    //          GLP_IV (+ GLP_BV optionally)
      prob_pure_zero_one   = 5,    //                    GLP_BV
      prob_other           = 9
    };

  class SolverIf                             // GLPK solver interface class
  {
  public:
    // ...
    ProblemKlass getProblemKlass() const;
  private:
    glp_prob* d_prob;                        // GLPK problem instance
  };

  ProblemKlass                               // an enumeration
  SolverIf::getProblemKlass() const
  {
    int nVars     = 0;                       // variables
    int nCons     = 0;                       // continuous variables
    int nNonCons  = 0;                       // integer and binary variables
    int nInts     = 0;                       // integer (excluding binary)
variables
    int nBins     = 0;                       // binary variables

    nVars    = glp_get_num_cols(d_prob);     // continuous, integer, and
binary variables
    nNonCons = glp_get_num_int(d_prob);      // integer and binary variables
    nBins    = glp_get_num_bin(d_prob);      // just binary variables

    nCons = nVars    - nNonCons;
    nInts = nNonCons - nBins;

    ProblemKlass klass = prob_not_specified; // initial value

    if ( nVars == 0 )                        // no variables loaded
      {
        klass = prob_linear;                 // an empty problem is deemed
linear!
      }
    else                                     // a substantial problem
      {
        if ( nCons == 0 )                    // pure not mixed nonlinear
          {
            if ( nInts == 0 )                // no integers present
              klass = prob_pure_zero_one;
            else                             // integers present
              klass = prob_pure_integer;
          }
        else if ( nNonCons == 0 )            // linear
          {
            klass = prob_linear;
          }
        else                                 // mixed nonlinear
          {
            if ( nInts == 0 )                // no integers present
              klass = prob_mixed_zero_one;
            else                             // integers present
              klass = prob_mixed_integer;
          }
      }

    return klass;
  }

> As to glp_empty_prob, I think it is equivalent to
> existing api routine glp_erase_prob. If you remove all
> rows and columns, there is no useful internal
> information that would need to be retained.

Okay.  If the the caller wants to recycle the problem
name (as I do), then the caller can recover the name
and then explicitly set it again.  This particular API
suggestion thus offers nothing of real value.

>> 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.
>
> I don't think so. To access the glpk environment
> glp_term_out calls get_env_ptr, which, in turn, calls
> glp_init_env, if necessary (please see src/glpenv03.c).

Okay.  I am a little confused here.  I need to make a
test to confirm that I am wrong!

>> Hence, the following (currently hypothetical) API might
>> be useful:
>>
>>     int glp_init_env()  /* returns zero on success */
>
> Exactly this api routine exists and is documented, including its
> counter-part glp_free_env.

Oops.

>> ---------------------------------
>>  API request : glp_combine
>> ---------------------------------
>
> The purpose of this routine is unclear, because there
> may be many different ways in which two or more
> problems can be combined.

I was thinking of simply adding row and column
information from the second problem to the first by
some repeated application of GLPK row and column add
and set calls.  Whether this API would be intuitive and
useful is another question.  Furthermore, the task can
readily be undertaken the client-side with the exact
semantics the programmer requires.  This API suggestion
was more a passing thought on my part and should
probably be dropped.

thanks again
Robbie
---
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 Webmail client]