-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Handle correctly cancelled run #5695
Changes from 2 commits
ad98c2d
6770ed8
9c0afc4
96aa2a0
4df76f1
5519e22
0ead8fe
db67c91
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -179,11 +179,17 @@ void lar_core_solver::solve() { | |
} | ||
lp_assert(!settings().use_tableau() || r_basis_is_OK()); | ||
} | ||
if (m_r_solver.get_status() == lp_status::INFEASIBLE) { | ||
switch (m_r_solver.get_status()) | ||
{ | ||
case lp_status::INFEASIBLE: | ||
fill_not_improvable_zero_sum(); | ||
} | ||
else if (m_r_solver.get_status() != lp_status::UNBOUNDED) { | ||
break; | ||
case lp_status::CANCELLED: | ||
case lp_status::UNBOUNDED: // do nothing in these cases | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. theory_lra only checks against lp_status::OPTIMAL when deciding whether to re-check feasiblity in final_check_eh. Now UNBOUNDED would likely leak too. So shouldn't theory_lra condition the status on being feasible, where feasible is one of OPTIMAL, UNBOUNDED or so? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it seems the right approach. I can fix it later. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The question is how theory_lra handles the return codes. Can we always assume that if the status is OPTIMAL, FEASIBLE, UNBOUNDED that all bounds are satisfied? If so, then there are two places to change in theory_lra. It makes no assumptions about feasibility with UNBOUNDED. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. Or, lp can have a boolean function, smth like, feasible_status(lp_status), providing this abstraction. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes please |
||
break; | ||
default: // adjust the status to optimal | ||
m_r_solver.set_status(lp_status::OPTIMAL); | ||
break; | ||
} | ||
lp_assert(r_basis_is_OK()); | ||
lp_assert(m_r_solver.non_basic_columns_are_set_correctly()); | ||
|
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.
why are you removing this?
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.
It cannot happen if the column is feasible. And we assume here that it is feasible. We have l <= 0 <= u during this loop. Then we adjust l and u by shifting to xj.
I meant it cannot happen when all columns are feasible.
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.
It seems to me that you are baking in some assumptions about the calling context. Maybe the current calling context is that the tableau is feasible, but this code would be easier to maintain if it doesn't rely on strong assumptions.
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.
The calculation will be incorrect if at least one of the basic columns 'i ' is infeasible. The feasibility assumption is already baked in to the code as I understand it.
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.
Actually, the code seems to be correct even when some i is infeasible. Going to reverse the change related to get_freedom...
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.
From the other side, if we consider the infeasible case, we cannot just "continue" the loop on l==u, expecting that further on we might encounter another infeasible variable that will create l > u!
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.
It looks like we have some optimizations for the feasible case that are not available in general.
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.
at minimum add an assertion to enforce whatever contract you assume