Fix column bounds in findLowerLevelSolImprovingDirectionIC() #143
Conversation
| // feb223: w = 0 should be always a feasible direction | ||
| nSolver->setColLower(i, CoinMin(ceil(origColLb[colIndex] - value - | ||
| localModel_->etol_), 0.0)); | ||
| nSolver->setColUpper(i, CoinMax(floor(origColUb[colIndex] - value + |
There was a problem hiding this comment.
Ugh, I really don't understand code editors the introduce weird indentation. We need a workflow that runs the code through a formatter on every commit.
There was a problem hiding this comment.
This doesn't seem right, now that I'm looking at it. It's a numerical issue, not an issue of forcing 0 to be feasible. We shouldn't have to force this by doing min/max. The issues is more like that the floor operator just isn't correct if the thing you're applying the 'floor` to might already be below what it's true value is supposed to be. There are a couple of possibilities.
- If
valueis supposed to be integer, then rounding it before setting bounds should be valid and would fix this particular issue. Of course, technically, you should round the whole solution and make sure it remains feasible, yada, yada. - Alternatively, if the bound is supposed to be integer, it seems like rounding it should also be correct.
With something like a cut, you want to be conservative in rounding, always rounding the direction that relaxes the cut, to avoid removing a feasible solution that should not be removed. But here, we also want to be careful not to generate directions that actually aren't feasible, so you don't want a bound that is too loose either. I guess you really need the bound to be the exact correct value.
The point is that I guess this is not just an issue of whether zero, in particular, is feasible or infeasible, but is an issue of having the correct bounds in any case, not just when they are zero.
Guarantee in the MILP subproblem for finding an ImprovingDirection, 0 is always a feasible value for each variable.