> Hi, > > I am using the latest version of GLPK to solve the attached MIP > problem (seed.mps), and I am getting the following result: > > Solver: GLPK_CMD > Status: Optimal > Objective: 4450.011933000001 > x0 = 18, x1 = -24, x2 = -37, x3 = 9, x4 = -3, x5 = -48, x6 = 16, x7 = > 9, x8 = -13.3293, x9 = 23.8585 > > While all the other solvers I have tried (including CBC, SCIP, HiGHS > and Gurobi) return the same result as following: > > Solver: CBC, SCIP, HiGHS, Gurobi > Status: Optimal > Objective: 4485.181539630002 > x0 = 18, x1 = -24, x2 = -37, x3 = 9, x4 = -4, x5 = -48, x6 = 16, x7 = > 9, x8 = -13.575019, x9 = 23.694121 > > Is this result expected for GLPK? I'm not sure if this difference of > the answer is due to a different algorithm used by GLPK or it’s an > implementation issue. Any response or suggestions are appreciated! > > Thanks for your time! > > Best wishes, > Xintong Zhou > Cheriton School of Computer Science > University of Waterloo >
Thank you for your report. CBC, SCIP, HiGHS, and Gurobi report correct solution. Solving your instance with glpk I found that some constraints in the optimal solution are slightly violated, e.g. row _C756 has lower bound 83.06 while in the solution its activity is 83.0599. So the glpk solution is not buggy but has low precision. I think this effect can be eliminated by reformulating your model; in particular, using integer variables with large bounds (-200 .. 200) seems to me not a good idea. Andrew Makhorin
