> > Sure, both cases are trivial, I > am only not sure what the call > > would result? Would there be some bad consequences of > you call that > > way? > > Primal values (activities) of rows and columns can be > obtained with > routines glp_get_row_prim/glp_get_col_prim, and the dual > values > (reduced costs) can be obtained with > glp_get_row_dual/glp_get_col_dual. > Row/column statuses are reported by routines > glp_get_row_stat and > glp_get_col_stat. >
Sure, Andrew, this is good stuff. But I am considering from a little different angle: the API friendliness. Suppose you need to get the sensitivity bounds for a variable or constraint, you will have to first find out its status by glp_get_row_stat or glp_get_col_stat, then decide if you should call the corresponding sensitivity analysis API routine, or you should rather deal with the case yourself, as the behavior of the sensitivity analysis API routine is not defined in that case (undocumented at least). But even though it is a trivial thing to implement, you could still need other API routines or data structures to make things right. This is not very API friendly, is it? So if it is not two ugly, why not have those cases included into the sensitivity analysis routines, just for the sake of completeness and API friendliness? Yingjie _______________________________________________ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk