Hello Andrew Many thanks for considering my suggestions. Some comments follow.
------------------------------------------------------------ To: Robbie Morrison <[email protected]> Subject: Re: [Help-glpk] new APIs : some suggestions Message-ID: <1303488164.2960.23.camel@corvax> From: Andrew Makhorin <[email protected]> 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) : [email protected] Webmail (preferred) : [email protected] [from Webmail client] _______________________________________________ Help-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-glpk
