> Sure, both cases are trivial, I am only not sure what the call
> would result? Would there be some bad consequences of you call that
> way?
Primal values (activities) of rows and columns can be obtained with
routines glp_get_row_prim/glp_get_col_prim, and the dual values
(reduced costs) can be o
Hi everybody,
I have some misunderstand about GLPK's sensitivity analysis. I read several times the GLPK documentation but some details no more clear for me.
Let investigate the following problem:
max
9x1+20x2+45x3
subject to
2x1+5x2+15x3<=5000
4x1+6x2+8x3<=2
end
I get the following
> I have some misunderstand about GLPK's sensitivity analysis. I read
> several times the GLPK documentation but some details no more clear
> for me.
> Let investigate the following problem:
> max
> 9x1+20x2+45x3
> subject to
> 2x1+5x2+15x3<=5000
> 4x1+6x2+8x3<=2
> end
> I get the following ou
> I read again the documentation. The Chapter 4 helped me a lot. But I
> still do not understand the sensitivity analysis exactly.
> Let see again the the problem:
>
> max
> 9x1+20x2+45x3
> subject to
> c1:2x1+5x2+15x3<=5000
> c2:4x1+6x2+8x3<=2
> end
>
> For the second constraint I get an
> unlimitedly increase, value of c2 would be 1 (which is its upper
> bound).
Must read "which is its an implied upper bound due to other
constraints".
___
Help-glpk mailing list
Help-glpk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-glpk
Hi,
I wonder if there is a simply way to print a sensitivity analysis table below
with an LP in glpk?
variable, value, allowed decrease, allowed increase
x[1] ,5.0, 2.0, 4.0
x[2],
row,shadow, allowed decrease, allowed increase
r[0],
> I wonder if there is a simply way to print a sensitivity analysis
> table below with an LP in glpk?
Look at the routine lpx_print_sens_bnds (file glpk/src/glplpx03.c).
It implements the glpsol option --bounds.
___
Help-glpk mailing list
Help-glpk@gn
> > I wonder if there is a simply
> way to print a sensitivity analysis
> > table below with an LP in glpk?
>
> Look at the routine lpx_print_sens_bnds (file
> glpk/src/glplpx03.c).
> It implements the glpsol option --bounds.
Thanks for that information. I checked the source code, and wonder if t
> Look at the routine lpx_print_sens_bnds (file
> glpk/src/glplpx03.c).
> It implements the glpsol option --bounds.
I was wondering about if LPX_OPT == GLP_OPT
when checking the solution status? It seems
pyglpk used GLP_OPT while the routine
lpx_print_sens_bnds(...)
used LPX_OPT, and I got wro
> I was wondering about if LPX_OPT == GLP_OPT
> when checking the solution status?
No, LPX_OPT != GLP_OPT. (LPX_OPT macro is deprecated and should not
be used.)
> It seems
> pyglpk used GLP_OPT while the routine
> lpx_print_sens_bnds(...)
> used LPX_OPT, and I got wrong outputs.
lpx_print_se
> Thanks for that information. I checked the source code, and wonder if
> there is a way to have the output go to the standard output. Currently
> I only saw a possibility that requires a little change to the source
> code:
> The prototype is:
> int lpx_print_sens_bnds(LPX *lp, const char *fnam
> Writing to stdout should be supported by xfopen in the same way as it
> supports, for example, .gz files, i.e. something like this:
>fp = xfopen("/dev/stdout", "w");
> where "/dev/stdout" is a special filename recognized within xfopen
> (may be using "-" would be even better). This would al
BTW,
glpsol --bounds /dev/stdout
must work under Linux while
glpsol --bounds CON
must work under Windows.
___
Help-glpk mailing list
Help-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/help-glpk
> BTW,
>
> glpsol --bounds /dev/stdout
>
> must work under Linux while
>
> glpsol --bounds CON
>
> must work under Windows.
>
>
Great! This answers my previous question (please disregard that one). Thanks a
lot!
___
Help-glpk mailing l
> BTW,
>
> glpsol --bounds /dev/stdout
>
> must work under Linux while
>
> glpsol --bounds CON
>
> must work under Windows.
>
>
I tried it on my mac os x and /dev/stdout also corresponds to the standard
output (since it is a unix variant).
The problem is, of course, the out-dated LP
> I tried it on my mac os x and /dev/stdout also corresponds to the
> standard output (since it is a unix variant).
> The problem is, of course, the out-dated LPX_OPT. Even after glpsol
> found the optimal solution, I still got the output saying:
> "
> ...
> Size of triangular part = 1
>
> This is a scaling/tolerance issue, i.e. glp_simplex reports that
> the status is optimal, but glp_warm_up does not agree with that.
> Please replace line 70, file glplpx03.c:
> lpx_warm_up(lp);
> by the following line:
> glp_factorize(lp);
> This must help.
> (I will try to re-i
Saturday, December 26, 2009, 11:02:20 AM, you wrote:
>> I tried it on my mac os x and /dev/stdout also corresponds to the
>> standard output (since it is a unix variant).
>> The problem is, of course, the out-dated LPX_OPT. Even after glpsol
>> found the optimal solution, I still got the output
> Another way is just disable the lp presolver (--nopresol).
I tried the --nopresol switch, and still got the same result.
My glpsol version is 4.39. I think I will look forward to the new release.
I wonder if it is possible for the API to support printing the sensitivity info
for just one part
>
> I wonder if it is possible for the API to support printing
> the sensitivity info for just one particular
> variable/constraint? This is useful when one is only
> interested in some of the sensitivity bounds.
>
It might be even better if the API has routines to
calculate the max increase an
> It might be even better if the API has routines to
> calculate the max increase and max decrease of the
> bounds, for example:
> /**sensitivity bounds for coeficient in the objective*/
> glp_coef_sensit_bounds(GLP* lp, int var_idx,
>double* max_dec, double* max_inc);,
> /**sensitiviy bound
>> I wonder if it is possible for the API to support printing
>> the sensitivity info for just one particular
>> variable/constraint? This is useful when one is only
>> interested in some of the sensitivity bounds.
>>
> It might be even better if the API has routines to
> calculate the max incre
> The information in sensitivity analysis table in glpk seems to be
> incorrect.
>
> For example: for the problem in sample.c file and in the manual
> section 1.3.1 (page 14).
>
[...]
> However the correct range of the row r would be 200-> +inf not (120->
> 520).
>
> Do I miss something here
> For detailed explanations of the report structure please see Section 3.4
> "Post-optimal analysis routines" in the glpk reference manual,
> pp.107-114.
>
You need reading the paragraph "Sensitivity analysis of objective
coefficients at basic variables" on pp.112-113.
> >If a row is non-active, changing its bounds does not affect the basic
> solution.
> This is only true for small change but not true for large change.
No, this is true for any change, assuming that a new lower bound remains
not greater than and a new upper bound remains not less than the curre
25 matches
Mail list logo
