Skip to content

Replace hardcoded canonical rule examples with ILPSolver calls #772

@isPANN

Description

@isPANN

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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions