-
Notifications
You must be signed in to change notification settings - Fork 4
Description
Problem
Several ILP reduction rules have hardcoded source_config / target_config in their canonical_rule_example_specs() instead of dynamically computing them via ILPSolver::new().solve(). This means the canonical examples don't actually verify that the ILP solver can solve the reduction — they just check that a pre-computed solution pair is consistent.
Affected rules
All 7 are ILP<bool> or ILP<i32> targets:
| Rule | Target | Notes |
|---|---|---|
capacityassignment_ilp |
ILP<bool> |
|
longestcommonsubsequence_ilp |
ILP<bool> |
|
minimumcutintoboundedsets_ilp |
ILP<bool> |
|
multiplecopyfileallocation_ilp |
ILP<bool> |
|
sumofsquarespartition_ilp |
ILP<bool> |
|
minmaxmulticenter_ilp |
ILP<i32> |
needs z upper bound for HiGHS perf |
shortestweightconstrainedpath_ilp |
ILP<i32> |
needs variable bound constraints for HiGHS perf |
Expected fix
Replace the hardcoded SolutionPair { source_config: vec![...], target_config: vec![...] } with the standard pattern:
let reduction = ReduceTo::<ILP<V>>::reduce_to(&source);
let ilp_solution = crate::solvers::ILPSolver::new()
.solve(reduction.target_problem())
.expect("canonical example must be solvable");
let source_config = reduction.extract_solution(&ilp_solution);For ILP<i32> targets, ensure all auxiliary variables (z, position, flow) have explicit single-variable upper bound constraints (var <= C) so HiGHS doesn't see a [0, 2^31] domain and hang.
Context
These were introduced during the Group A ILP rewrites in #771 (upgrade decision models to optimization). The ILP<bool> ones should be trivial to convert. The ILP<i32> ones may need additional bound constraints in the ILP formulation first.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status