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

[Yingjie Lan]

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

OK, I somehow had a wrong impression that your API routine
would calculate ranges for both lower and upper bounds.
Your choice of API this way is interesting, when
I looked into your code for glp_report_range(), 
it seems you are playing with duality nicely.
But it is probably more fool-proof if your API 
provides a more direct approach? Just like how
you look at the sensitivity report table, where 
API would simply give the information for
any particular row of the table. I don't know,
maybe I am too way off the track.

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

That's true, as I check with the code. 
It is not in the document. 
I should have checked the code first. 

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

Though it is trivial, but still it is ideal if the
routine provides a complete functionality and a fool-proof API
so that you don't even have to worry about the knowledge anymore.
Well, probably that's a little lazy ...

Yingjie