fix check of MIP solution using wrong tolerances

[lgottwald]

This should fix issue #559

[lgottwald]

@jajhall Do you think we should change "primal_feasibility_tolerance" to "lp_primal_feasibility_tolerance" so that it is clear that this is for the LP solver (same for "lp_dual_feasibility_tolerance")?

[odow]

Is there a list of the tolerances and what they refer to explicitly?

Following something like Gurobi, it makes sense to have:

• primal_feasibility_tolerance
• dual_feasibility_tolerance
• integrality_tolerance

I'm not sure it makes sense to have a mip_primal_ and lp_primal_ feasibility tolerances (if they refer to the affine constraints) that are different?

[lgottwald]

The mip_feasibility_tolerance is used for constraints and integrality restrictions. The reason is that the MIP solver works a bit differently regarding scaling and what it can do to get rid of small violations. When I started the development I did not want to change the default tolerance of the LP solver and 1e-7 seemed a bit strict for MIP. In the LP solver it is not clear that a less strict tolerance would even help performance as it restricts the choice of pivots and the LP is usually scaled so the LP solver works in a scaled space and tolerances of 1e-7 can usually be attained.

In MIP, however, integral columns cannot be scaled and constraints that are integral are also not scaled currently as their slack variables can be used for separation. In the future I may change the mechanism by which integrality of slack variables is exploitet so that it allows scaling the constraints regardless. Moreover, the feasibility tolerance in MIP is not only used for model constraints but also for cutting planes which are generated subject to rounding errors. A MIP solution that violates a constraint might not be as easily repairable as an LP solution due to its discrete nature. For the simplex, up to machine precision, in principle further pivots can be used to get rid of infeasibilities which is not the case for a MIP solution. Trying to repair a MIP solution that is feasible with tolerance 1e-6 to be feasible for tolerance 1e-7 is not guaranteed to succeed even if a solution that is feasible with that tolerance exists.

So for now I'd like to keep the separate mip_feasibility_tolerance, at least for the first release. Also there are no further tolerances used I think, so your list would be complete. There are a few other numerical parameters, e.g. "small_matrix_value", and there is "ipm_optimality_tolerance" but no other feasibility tolerance I believe.

[odow]

Thanks. That makes sense.

[jajhall]

This is fine by me!

[jajhall]

In passing @odow do you have this document relating to options?

It's generated by HiGHS with the call writeOptions(const std::string filename)
Options.set.txt

[odow]

do you have this document relating to options?

No I hadn't seen this! I will add it to the Github readme for HiGHS.jl.

[odow]

Options are now documented: https://github.com/jump-dev/HiGHS.jl#options

Thanks Julian.