-
Notifications
You must be signed in to change notification settings - Fork 5
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
Translate empty row rule and reduction to apply! interface #13
Conversation
Codecov Report
@@ Coverage Diff @@
## master #13 +/- ##
==========================================
+ Coverage 46.56% 46.83% +0.27%
==========================================
Files 13 14 +1
Lines 902 901 -1
==========================================
+ Hits 420 422 +2
+ Misses 482 479 -3
Continue to review full report at Codecov.
|
…dn't make the port over from Tulip.
src/lp/empty_row.jl
Outdated
Sets the dual variable $y\_lower_{i} = \max\{0,y\}$ for the greater-than | ||
constraint and the dual variable $y\_upper_{i} = \max\{0,-y\}$ for the | ||
less-than constraint. |
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.
Small clarification.
Unless row i
is infeasible, both dual multipliers y_l
and y_u
are zero: this corresponds to the reduction EmptyRow(i, zero(T))
, which is created in the non-infeasible case.
Thus, the y_l = max(0, y)
, y_u = max(0, -y)
in the post-solve only yield non-zero values if the row was infeasible.
My rationale for initially doing so was to have "status-agnostic" reductions and postsolve.
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.
Updated the doc, let me know what you think.
src/lp/empty_row.jl
Outdated
We eliminate row $i$ if, for each variable index $j$, | ||
``math | ||
| a_{i,j} | ≤ ϵ | ||
``` | ||
for prescribed tolerance $ϵ$. |
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 don't see this being done in the code, is it on purpose?
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.
Hmm no, I wrote this first and then never followed through on it. Do we want to do this? If so, at what point? It feels a bit weird to do it in load_problem!
: if the user is passing us the matrix with small nonzeros, it seems like we should respect that.
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.
If we do it, I would rather put it in a different rule, with a drop tolerance for rounding small values to zero and large ones to infinity.
As for the where, once at the beginning of presolve seems reasonable. See also #12 (comment)
Co-authored-by: mtanneau <9593025+mtanneau@users.noreply.github.com>
…compute row sparsity
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.
Can you add an entry in the docs as well?
Co-authored-by: mtanneau <9593025+mtanneau@users.noreply.github.com>
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.
LGTM, thanks!
No description provided.