Now mapping to kHighsInf, any bounds on (semi-)integer variables that are not less than 1e9

[jajhall]

Description

Ridiculous large finite bounds on integer variables caused a failure addressed by #3241

Removed infinite bound of 1e9 for integers, but added separate continuous and noncontinuous bound analysis, and warning statement for badly-scaled models

Checklist

• I have read the contributing guidelines
• This PR targets the latest branch
• Tests are passing
• Documentation was updated where relevant
• This PR is not primarily AI-generated (per the AI contributions policy in CONTRIBUTING.md)

[codecov]

Codecov Report

❌ Patch coverage is 95.45455% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.24%. Comparing base (f1de972) to head (bf989e9).
⚠️ Report is 923 commits behind head on latest.

Files with missing lines	Patch %	Lines
check/TestModelProperties.cpp	91.66%	1 Missing ⚠️
highs/lp_data/HighsSolve.cpp	96.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           latest    #3243      +/-   ##
==========================================
+ Coverage   73.16%   73.24%   +0.07%     
==========================================
  Files         430      445      +15     
  Lines      103967   108105    +4138     
  Branches    16719    17328     +609     
==========================================
+ Hits        76067    79180    +3113     
- Misses      27624    28649    +1025     
  Partials      276      276              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Opt-Mucca]

I don't mind this change, but I do worry 1e9 is too small here (don't see an easy way that we can increase it).

We'd now risk giving "infeasible" solutions for people who modelled with such large bounds.

[fwesselm]

@jajhall, just one question regarding hard-coding the 1e9.

[jajhall]

I don't mind this change, but I do worry 1e9 is too small here (don't see an easy way that we can increase it).

We'd now risk giving "infeasible" solutions for people who modelled with such large bounds.

No, as the change relaxes the bounds on such columns. So unboundedness is the "risk".

However, if someone sets 1e9 as a bound that might be active in an optimal solution they are asking for trouble. Even the simplex solver may fail as 1e9/primal_feasibility_tolerance is 1/double_precision.

The reason for the infinite_bound option is that some folk will not know the value to use for an "infinite" bound, so just put something large. To be honest, allowing them to vary the value of the infinite_bound option from its default value of 1e20 (with no upper limit!) gives the misleading impression that they can have meaningful bounds greater than 1e20. If it were not for the prospect of having some internal problem scaling facility, I'd be in favour of reducing the default value to 1e12, and only allowing users to reduce it - with the only lower limit being zero.

[Opt-Mucca]

No, as the change relaxes the bounds on such columns. So unboundedness is the "risk".
However, if someone sets 1e9 as a bound that might be active in an optimal solution they are asking for trouble. Even the simplex solver may fail as 1e9/primal_feasibility_tolerance is 1/double_precision.

It's not that uncommon for users to model terms with 1e+9. I'm quite afraid of such unbounded cases.
What I meant with "infeasible" solutions is that the integral bound doesn't have to be tight to change the optimal solution drastically. There may have been an optimal solution around x ≈ 1e+5, but now another "optimal" solution at x ≈ 1e+10 can pop up despite the user having modelled that they don't want it with the x <= 1e+9 bound (not going to be common, but not so ridiculous to imagine).

[Opt-Mucca]

Happy with the change now! I'd still suggest using kExcessivelyLargeBoundValue instead of 1e4, but can live with the compromise

[fwesselm]

Thanks, @jajhall! Just minor questions from me.

[jajhall]

Happy with the change now! I'd still suggest using kExcessivelyLargeBoundValue instead of 1e4, but can live with the compromise

OK, I've raised it to 1e5 ;-)