Closed syxolk closed 5 years ago
I do not trust glpk or CBC results.
So I would say yes.
Even gurobi and cplex can disagree. It comes with the technology.
Le lun. 29 juil. 2019 à 05:49, Hans notifications@github.com a écrit :
Hi, I'm using OR-Tools 7.2 (Python 3) with GLPK 4.65. When running the following code, I receive a result status of ABNORMAL instead of INFEASIBLE (as observed with Gurobi 8.1 and CBC):
from ortools.linear_solver import pywraplp
solver = pywraplp.Solver('test', pywraplp.Solver.GLPK_MIXED_INTEGER_PROGRAMMING) solver.EnableOutput() x = solver.IntVar(0, 10, "") solver.Add(x >= 20)
result_status = solver.Solve()print(result_status)
GLPK output:
Scaling... A: min|aij| = 1.000e+00 max|aij| = 1.000e+00 ratio = 1.000e+00 Problem data seem to be well scaled Constructing initial basis... Size of triangular part is 1 GLPK Simplex Optimizer, v4.65 1 row, 1 column, 1 non-zero Preprocessing... PROBLEM HAS NO PRIMAL FEASIBLE SOLUTION
Is this expected behavior?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/or-tools/issues/1459?email_source=notifications&email_token=ACUPL3PODAVADJ3NMBIH6FLQB3RPLA5CNFSM4IHSCSY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HCBFPLQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ACUPL3JH3HLOG7TKVRXZUKTQB3RPLANCNFSM4IHSCSYQ .
Ok, I thought this a mapping problem of GLPK status codes to OR-Tools status codes.
Status code are very different across solvers. I believe GLOP returns ABNORMAL if the problem is proved infeasible during presolve, and INFEASIBLE is proved during search. Something like that.
Your code should check for both abnormal or infeasible. Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53 00
Le mar. 30 juil. 2019 à 11:30, Hans notifications@github.com a écrit :
Ok, I thought this a mapping problem of GLPK status codes to OR-Tools status codes.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/google/or-tools/issues/1459?email_source=notifications&email_token=ACUPL3MVRA2BO5THSYAIJJDQCCCC3A5CNFSM4IHSCSY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3E4AMI#issuecomment-516538417, or mute the thread https://github.com/notifications/unsubscribe-auth/ACUPL3KSJVERXTOIYQTUKX3QCCCC3ANCNFSM4IHSCSYQ .
Your code should check for both abnormal or infeasible.
Thanks for the suggestion! I thought ABNORMAL
is some kind of unknown state of the solver itself.
Just for the record, I found some relevant information in the glpk_interface code:
This is probably what was happening in my minimal example, especially since it stops directly after "Preprocessing..."
I do not trust glpk or CBC results. So I would say yes. Even gurobi and cplex can disagree. It comes with the technology. Le lun. 29 juil. 2019 à 05:49, Hans notifications@github.com a écrit :
Are there open source solvers you would trust?
Hi, I'm using OR-Tools 7.2 (Python 3) with GLPK 4.65. When running the following code, I receive a result status of
ABNORMAL
instead ofINFEASIBLE
(as observed with Gurobi 8.1 and CBC):GLPK output:
Is this expected behavior?