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

[Yingjie Lan]

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

Sure, that's true. But all you need is just the range.
the range reflects what you said about active bounds.
 
> 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?
> 

There is surely a trade off: on the one hand is the 
inconvenience for the user to adapt the API to their 
needs, on the other hand is the clumsiness of the API,
which clutters up the API for the user. In the case
you provided above, the inconvenience is minimal, as
converting from degrees to radians is easy; but if you
have to do both, you probably need to do something
like this: sin_radian(x), sin_degree(x); Or you could
do sin(x, radian), where radian can be 1 or 0. 
The first is a really bad design, the second is still
not too good, because most of the case in scientific
usage people use radians.

But in GLPK sensitivity analysis, the API would not
be affected if you allow more complete functionality, 
just same routines, but with much more convenience.
The documentation is easier to write and remember, 
for you don't have to say that the user must first 
make sure to use basic variables, otherwise the 
outcome is unpredictable.

Yingjie