Fix loose tolerances in the objective function integrality detection

[aliceb-nv]

The objective function integrality detection was relying on weak tolerances, which caused neos-827175 to be incorrectly accounted as integral and causing an incorrect solution bound to be reported. (objective coefficients were as low as 1e-5)

This PR uses a tighter 1e-9 tolerance for integrality detection in the objective function to avoid such issues.

Description

Issue

Checklist

• I am familiar with the Contributing Guidelines.
• Testing
  • New or existing tests cover these changes
  • Added tests
  • Created an issue to follow-up
  • NA
• Documentation
  • The documentation is up to date with these changes
  • Added new documentation
  • NA

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[coderabbitai]

📝 Walkthrough

Walkthrough

Modified objective integrality recomputation in the problem solver to use a dedicated is_integer<f_t> predicate with 1e-9 tolerance instead of the prior method, and expanded the integrality criterion to include variables flagged as VAR_IMPLIED_INTEGER alongside explicit integer types.

Changes

Cohort / File(s)	Summary
Objective integrality logic cpp/src/mip_heuristics/problem/problem.cu	Updated integrality check to use dedicated is_integer<f_t> predicate with 1e-9 tolerance; expanded criterion to include both var_t::INTEGER type and VAR_IMPLIED_INTEGER flag; modified control flow condition for objective scaling to evaluate integrality with tighter tolerance and implied-integer status.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: tightening tolerances in objective function integrality detection to fix a bug where weak tolerances caused incorrect classification.
Description check	✅ Passed	The description clearly explains the issue (loose tolerances causing incorrect integrality detection), the specific problem case (neos-827175 with 1e-5 coefficients), and the solution (applying 1e-9 tolerance).
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

cpp/src/mip_heuristics/problem/problem.cu (1)

1359-1359: Use epsilon-based zero checks instead of exact == 0 for objective coefficients.

Line 1359 and Line 1372 use exact floating-point equality. Near-zero coefficients after transforms can be misclassified by exact zero checks.

Patch sketch

 void problem_t<i_t, f_t>::recompute_objective_integrality()
 {
   using cuopt::linear_programming::detail::is_integer;
+  constexpr f_t objective_zero_tol = 1e-12;

   objective_is_integral =
     thrust::all_of(handle_ptr->get_thrust_policy(),
                    thrust::make_counting_iterator(0),
                    thrust::make_counting_iterator(n_variables),
                    [v = view()] __device__(i_t var_idx) -> bool {
-                     if (v.objective_coefficients[var_idx] == 0) return true;
+                     auto c = v.objective_coefficients[var_idx];
+                     if (raft::abs(c) <= objective_zero_tol) return true;
                      // Need a tight tolerance for integrality to weed out instances like
                      // neos-827175 with very small objective coefficients
-                     return is_integer<f_t>(v.objective_coefficients[var_idx], 1e-9) &&
+                     return is_integer<f_t>(c, 1e-9) &&
                             ((v.variable_types[var_idx] == var_t::INTEGER) ||
                              (v.var_flags[var_idx] & (i_t)VAR_IMPLIED_INTEGER));
                    });

   bool objvars_all_integral =
     thrust::all_of(handle_ptr->get_thrust_policy(),
                    thrust::make_counting_iterator(0),
                    thrust::make_counting_iterator(n_variables),
                    [v = view()] __device__(i_t var_idx) -> bool {
-                     if (v.objective_coefficients[var_idx] == 0) return true;
+                     if (raft::abs(v.objective_coefficients[var_idx]) <= objective_zero_tol) return true;
                      return (v.variable_types[var_idx] == var_t::INTEGER) ||
                             (v.var_flags[var_idx] & (i_t)VAR_IMPLIED_INTEGER);
                    });

As per coding guidelines, "Check numerical stability: prevent overflow/underflow, precision loss, division by zero/near-zero, and use epsilon comparisons for floating-point equality checks".

Also applies to: 1372-1372

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@cpp/src/mip_heuristics/problem/problem.cu` at line 1359, The code uses exact
equality checks against zero for objective coefficients
(v.objective_coefficients[var_idx] == 0) at the two locations noted; replace
these with an epsilon-based comparison (e.g.,
fabs(v.objective_coefficients[var_idx]) <= EPS) and define a sensible EPS
constant (or compute one from std::numeric_limits<double>::epsilon() scaled
appropriately) so near-zero coefficients are treated as zero; update both
occurrences (the checks around var_idx and the second instance) and include
<cmath> or use std::abs as needed.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@cpp/src/mip_heuristics/problem/problem.cu`:
- Line 1359: The code uses exact equality checks against zero for objective
coefficients (v.objective_coefficients[var_idx] == 0) at the two locations
noted; replace these with an epsilon-based comparison (e.g.,
fabs(v.objective_coefficients[var_idx]) <= EPS) and define a sensible EPS
constant (or compute one from std::numeric_limits<double>::epsilon() scaled
appropriately) so near-zero coefficients are treated as zero; update both
occurrences (the checks around var_idx and the second instance) and include
<cmath> or use std::abs as needed.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: b45088a8-b6c5-4a85-ab8f-5e0ddfba9153

📥 Commits

Reviewing files that changed from the base of the PR and between df03c13 and facf383.

📒 Files selected for processing (1)

• cpp/src/mip_heuristics/problem/problem.cu

[aliceb-nv]

/ok to test facf383

[nguidotti]

Approved! Thanks for the fix, Alice!

[aliceb-nv]

/merge