-
Notifications
You must be signed in to change notification settings - Fork 271
More LPI functions and optimality check #967
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better to assert optimality rather than returning None. Otherwise, some minor grammar things and it looks good.
Liding, can you create a branch on the main repo instead of working on a fork? It makes things very slightly easier :)
Co-authored-by: João Dionísio <[email protected]>
Co-authored-by: João Dionísio <[email protected]>
Co-authored-by: João Dionísio <[email protected]>
Co-authored-by: João Dionísio <[email protected]>
Could the optimality assertions be removed? The comment is just an unfortunate way to say that the user should make sure that there is a meaningful LP solution available. At least I am also interested in feasible primal and dual solutions. |
@DominikKamp Oh... but wait, the comment doesn't seem unfortunate, it seems very explicit in its requirements.
Do you know what made people write it like this? What would you change the comment to? Also, the C-side of the LPI needs to change, this cannot be just a comment in the documentation. |
The concern was
although primal and dual solutions have certain definitions. Then those comments were dumped (to scare users). If this would be a requirement, there were an assertion on the C-side, but this is not the case. |
Fair enough, but I'd still be in favor of being more explicit in the C-documentation, and potentially adding some assertions. Not of optimality, but of the non-existence of the state that yields unexpected behavior. I'll make a PR removing the assertions now |
@DominikKamp pushed directly to master 🤦 Does this comment work for you
Or should I revert? |
The problem is that LPI has a call to underlying LP solvers, something (like support of LPI param) is not defined there, thus leaving freedom to decide by C users, mostly developers. For pysciopt, I would see a better approach is not an assertion, we could change it to print a warning message "LP is not optimal", meaning that any reduced costs and duals are unreliable. |
Oh, I like a warning much better. Can you prepare a PR @lidingxu? |
The comment is okay although I do not see why we should get unreliable results. The LP solver needs to prove its claims. For an unbounded LP I expect a feasible LP solution. For an infeasible LP I expect at least a farkas solution. If you then should encounter a wrong result, it needs to be documented and fixed. |
For example, a primal simplex may not provide a feasible dual, if the problem is not solved optimal (if time limit is too small), the user needs a warning. |
If the user asks for an unavailable dual solution, an error makes sense. In this case there should still be a way to get an available primal solution. But should this check not happen in SCIP? |
The functions of lpi is implemented separately in lpi_xxxsolver.cpp. For example, in SCIPlpiGetSol of lpi_clp.cpp, the reduced cost is obtained directly from the CLP library:
SCIP seems not check the availability at all, I do not know whether the clp will check. |
Every LP solver should indicate whether the respective solution is available and based on this the interface can return an error if an unavailable solution is accessed. So a change in SCIP is definitely required as shown by this example. But this is individual to each LP solver, where it would make sense to start with SoPlex since we can maximize utility there. |
SCIP requires : Before calling SCIPlpiGetSol(), the caller must ensure that the LP has been solved to optimality, i.e., that SCIPlpiIsOptimal() returns true.
Optimality check is added for functions calling SCIPlpiGetSol(). For non-optimality call, None is returned. Memory issue in getRedCost() is fixed. More get functions are added.