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

This PR maps to kHighsInf, any bounds on (semi-)integer variables that are not less than 1e9

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 97.50000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 73.23%. Comparing base (2558084) to head (e7ffb41).
⚠️ Report is 3 commits behind head on latest.

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

Additional details and impacted files

@@           Coverage Diff           @@
##           latest    #3243   +/-   ##
=======================================
  Coverage   73.23%   73.23%           
=======================================
  Files         445      445           
  Lines      108043   108075   +32     
  Branches    17321    17328    +7     
=======================================
+ Hits        79120    79150   +30     
- Misses      28647    28649    +2     
  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.

[fwesselm]

Would it be worth having a separate option infinite_integer_bound (instead of hard-coding this)?

[jajhall]

I don't think so. There's no way we'd allow a larger value, and we don't need it to be any less for the original purpose.

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.

[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).