Fourier-Motzkin presolve - #3191
Conversation
…olveAddRowsDebugging3
…olveAddRowsDebugging5
…olveAddRowsDebugging6
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## latest #3191 +/- ##
==========================================
+ Coverage 72.77% 73.20% +0.42%
==========================================
Files 444 444
Lines 107469 108401 +932
Branches 17290 17504 +214
==========================================
+ Hits 78213 79350 +1137
+ Misses 28979 28774 -205
Partials 277 277 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Opt-Mucca
left a comment
Opt-Mucca
left a comment
There was a problem hiding this comment.
I've finished my first round of review. I've got the general gist, but I failed completely at some point to keep track of the lambdas and the basis postsolve is brutal...... I'm hoping all my comments are still valid. I'm just going to put down some comments and questions here:
- The functionality to add rows and columns during presolve is a must. This opens the door for other techniques. Is super cool that you've added it!
- In general I'm against adding "dead-code" to the repository, and I'd prefer not adding such a large feature if it's not enabled by default.
- Do you think there's a window of MIP instances where this is super helpful? 1% performance degradation isn't too bad, and I'd still be fine merging it if (1) we're confident that the chance of worst-case performance is near zero (2) it is really helpful for some family of instances we care about
- Is it helpful for LPs over a general test set? If so then I'd just enable it there by default.
| if (problemSizeReduction() > 0.05) continue; | ||
| // check if there were reductions | ||
| bool haveReductions = problemSizeReduction() > 0.05; | ||
| tryFourierMotzkin = haveReductions || numColsEliminatedFourierMotzkin > 0; |
There was a problem hiding this comment.
Were there any cases where it found further reductions in a second round?
| for (const auto& e : newRowEntries) newRowMark[e.col] = -1; | ||
|
|
||
| // remove near-zero entries | ||
| newRowEntries.erase( |
There was a problem hiding this comment.
Does any relaxation need to be done here as opposed to directly removing the coefficient?
There was a problem hiding this comment.
Good point. I checked the remaining presolve code, and currently coefficients with absolute value less than or equal to options->small_matrix_value are just treated as zero. Therefore, I would like to keep the code as it is right now for the time being. I am open to revisit this in the future.
Depending on what LP testing @fwesselm has done, I'll test over a good set of LPs - for both performance and number of iterations after postsolve (which can be a test of correctness for the dual/basis postsolve). |
|
I have merged |
4 participants
This PR adds the Fourier-Motzkin presolve reduction as described by Zhang, Y., Ploskas, N. & Sahinidis, N.V. A novel linear optimization presolve technique based on Fourier-Motzkin elimination. Math. Prog. Comp. 18, 345–378 (2026):