[CoinUtils-tickets] [COIN-OR Common Utilities] #67: postsolve in CoinPresolve does not correctly handle slack variables at bounds
COIN-OR Common Utilities
coin-trac at coin-or.org
Sun May 29 17:37:04 EDT 2011
#67: postsolve in CoinPresolve does not correctly handle slack variables at
bounds
-------------------+--------------------------------------------------------
Reporter: stefan | Type: defect
Status: new | Priority: critical
Version: trunk | Keywords:
-------------------+--------------------------------------------------------
Activating asserts in OsiPresolve::postsolve and running the Osi unittest
shows issues with the postsolve routines of !CoinPresolve.
It seems that slack variables may be set to status atLowerBound for rows
with infinite right hand side or set to atUpperBound for rows with
infinite left hand side.
Lou had a look into it and reports:
{{{
For reference, the notion of logical variable and row status enforced
by the OSI unit test is:
<= 0 < s < infty logical atLowerBound when constraint tight
>= -infty < s < 0 logical atUpperBound when constraint tight
Which is nicely compatible with upper-bounded logicals for range
constraints.
I repaired CoinPresolvePsdebug (minor collateral damage from the
config.h stuff) and added code to presolve_check_sol to check the row
status. Turns out that forcing_constraint_action::postsolve and
subst_constraint_action::postsolve were directly setting incorrect row
status, and slack_doubleton_action::postsolve was indirectly getting it
wrong via CoinPrePostsolveMatrix::setRowStatusUsingValue. All of these had
the atLowerBound/atUpperBound convention reversed. Falls into the category
of `why did anything work at all' because the relevant bits of code date
back to 2004, probably earlier. Apparently none of the previous
implementors using CoinPresolve were actually using the row status
information? Or were using it and changes will break lots of code? I'm not
looking forward to committing this.
Which leads to the obvious question `So what's really wrong?' I don't
have the solution yet, but right now the answer appears to be that row
bounds are not properly restored. The instances I'm seeing are uniformly a
value of 0 but should be ± infty. There is, of course, the possibility
that I introduced this bug while fixing the row status.
}}}
--
Ticket URL: <https://projects.coin-or.org/CoinUtils/ticket/67>
COIN-OR Common Utilities <http://projects.coin-or.org/CoinUtils>
Common data structures and linear algebra functions for COIN-OR projects
More information about the CoinUtils-tickets
mailing list