[Help-glpk] Re: API friendliness Re: sensitivity analysis

[Andrew Makhorin]

> 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?

The interpretation of sensitivity analysis results depends on the
row/column status, so in any case you need "to first find out its
status by glp_get_row_stat or glp_get_col_stat", don't you? For example,
changing an active bound affects primal activities while changing an
inactive bound does not.

As to completeness and friendliness, just a question. Imagine you have
a triginometric function library which includes sin, cos, tan, etc. for
angles measured in radians. Is the library incomplete and non-friendly,
because it does not include functions for angles measured in grades?