> 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 _______________________________________________ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk