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

[Andrew Makhorin]

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

(I meant french grades, not degrees :)

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

I don't think so. It is a common practice.

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

This would affect the api, because, for example, a non-basic variable
has exactly one active bound to be analyzed while in a general case a
variable may have one or two bounds or even no bounds.

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

Not unpredictable; glp_analyze_bound and glp_analyze_coef check the
row/column status and signal an error if the status is not valid.

It seems to me that it is normal for the user to write some wrapper
routines (like sin_degree above) which meet his particular needs.