New conflict status codes based on the needs of CPLEX and Gurobi #1091
Conversation
src/attributes.jl
Outdated
| NO_CONFLICT_EXISTS | ||
| NO_CONFLICT_FOUND | ||
| CONFLICT_FOUND | ||
| MINIMUM_CONFLICT_FOUND |
There was a problem hiding this comment.
Hmm. Couldn't we return NO_CONFLICT_FOUND for the timeout/limit statuses? And can't we just return CONFLICT_FOUND regardless of whether it is minimal? I don't think we need lots of statuses for this. It it likely going to be used infrequently for debugging purposes.
There was a problem hiding this comment.
In some cases, the solver hits the limit, but is still able to return a conflict. In that case, we would return CONFLICT_FOUND in many different situations.
To simplify a bit, we could merge NO_CONFLICT_EXISTS and NO_CONFLICT_FOUND.
There was a problem hiding this comment.
Another solution would have "hierarchical" codes. For instance, termination_status (or its IIS equivalent) would only return fine-grained codes; users may rely on other functions like has_found_optimum or has_ended_prematurely_but_has_a_solution to get higher-level information. I'm not sure the advantages would overweight the costs, though…
There was a problem hiding this comment.
What are the advantages of having fine-grain statuses for the IIS? Either the solver found one, or it didn't. I don't really care if it hit a time-out and returned the one it had, even if it wasn't minimal. If people want more control, they could use the solver-dependent methods.
There was a problem hiding this comment.
In the new commit, there are only four remaining statuses: not called, error, nothing to find, something has been found.
There was a problem hiding this comment.
Yeah, I think this makes more sense to me. Although we should probably wait for someone else to chime in.
There was a problem hiding this comment.
I can imagine that for some solver, it might be difficult to distinguish between whether it was not found because it does not exists or whether it was not found because of some other issue.
If we make it clear that NO_CONFLICT_FOUND does not exclude the fact that it might be because the problem is feasible then IMO we could also have NO_CONFLICT_EXIST. It provide some solver-independent useful information to know that it was not found not because it has a numerical issue but because there was none and it is sure of it.
There was a problem hiding this comment.
Okay, maybe I'm actually coming back round to what we have is okay.
We can return NO_CONFLICT_EXISTS if the solver proved there was no conflict, and NO_CONFLICT_FOUND if it hit a time limit etc without finding one.
|
I missed click when submitting the revision, it's not yet an approval |
|
I'm thinking about closing this PR. The improvements it brings are marginal at best. |
|
Thanks for exploring though. It's very useful to try out different things and see where they go. |
In response to jump-dev/CPLEX.jl#299 (comment)