Check for zero bug

[galabovaa]

Closes #2786

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 80.32%. Comparing base (e8559b9) to head (c3dde15).
⚠️ Report is 49 commits behind head on latest.

Files with missing lines	Patch %	Lines
highs/mip/HighsDomain.cpp	80.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           latest    #2788   +/-   ##
=======================================
  Coverage   80.31%   80.32%           
=======================================
  Files         348      348           
  Lines       86095    86099    +4     
=======================================
+ Hits        69150    69155    +5     
+ Misses      16945    16944    -1     

☔ View full report in Codecov by Sentry.
📢 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.

[fwesselm]

I have not read all the comments in the issue (sorry!), but here are my comments:

1. I do not like hard-coding values. Is there an existing tolerance that could be used?
2. On the other hand, why does the current code check for strict equality? Checking floating point numbers for strict equality rarely makes sense.
3. Would it be possible to count the number of bound changes found in the current iteration and stop if no new bounds are found? I can look into this if you like.

@Opt-Mucca , what do you think (in particular, regarding using a different criterion for exiting the loop)?

[jajhall]

I don't know what the current code does, but I was concerned that the test was being relaxed just to eliminate an infinite loop that occurs when using 32-bit doubles.

I'm concerned that the modification might compromise solver behaviour with 64-bit doubles, and it's important that this doesn't happen.

[jajhall]

Looking at the code, I see that it compares objective bounds. Since these can be very large, a relative difference seems to be necessary.

The existing tolerance that seems relevant to me is 'mip_rel_gap', but any change needs to understand the context of the code, and why @lgottwald coded it originally as an equality.

[Opt-Mucca]

@fwesselm Sorry for the late reply. I think the idea of counting bound changes is obvious and genius. I'm not seeing a way that the objective can change in that loop without making a bound change.

[jajhall]

Closed by #2807