Skip to content

Strategy for checking and adding reduction rules #768

@zazabap

Description

@zazabap

Current state

Metric Count
Problem types 115
Reduction edges 139
Connected components 21
Main component size 95
Isolated problems (zero reductions) 20
NP-hard problems unreachable from 3-SAT 76

Recent work: 63 ILP reductions (#763, #767), CustomizedSolver (#766), aggregation unification (#754). Refactoring (#765, #748) planned separately.

Open question: how should we grow the reduction graph with high confidence that each added rule is correct, non-trivial, and useful to domain experts?

Backlog

241 open issues on the project board, mostly from Garey & Johnson (1979):

Category Count Status
[Rule] labeled Good 19 Reviewed, ready
[Rule] unlabeled 131 Not yet reviewed
[Rule] labeled PoorWritten 4 Needs rewriting
[Model] labeled Good 8 Ready
[Model] labeled PoorWritten 32 Needs rewriting
[Model] unlabeled 3 Not yet reviewed
Labeled Wrong 12 Incorrect
Labeled Useless 6 No value
Other (architecture, enhancements) 26 Separate track

131 rule issues are unreviewed. The write-ups may not faithfully capture the original G&J constructions.

Proposed plan

1. Rule priority — what's worth implementing?

Priority Criterion
P0 Connects an isolated problem to the main component (20 orphans)
P1 Closes an NP-hardness proof gap from 3-SAT (76 unreachable)
P2 Provides a solver path to ILP, QUBO, or customized solver
P3 Well-known in the literature (Karp's 21, textbook standard)
P4 Exists in G&J but not commonly cited

A rule must satisfy at least one criterion. Higher-priority rules first.

Agree with this ranking? Reorder, add, or remove?

2. Verification bar — what do we require before merging?

Requirement When
Closed-loop tests + overhead verification + >95% coverage Always (existing)
(A) Literature citation — G&J section or paper reference Always
(B) Proof sketch in docs/paper/reductions.typ Always
(C) Expert sanity check — reviewer confirms construction Complex gadgets or obscure sources

Is (A)+(B) always too heavy? Is (C) needed more broadly? Or is tests-only sufficient?

3. Triage strategy for 131 unlabeled rule issues

  1. Start with the 19 Good rules — already reviewed
  2. Demand-driven: when we need a connection (orphan, proof gap, solver path), pull the issue, review, then implement
  3. Batch-triage by domain when going deep on a domain (see Q4)
  4. Close the 12 Wrong + 6 Useless issues — misleading as-is

Agree with closing Wrong/Useless? Should we salvage any first? Is demand-driven the right pace?

4. Domain focus order

Order Domain Orphans to connect Good rules
1st Graph optimization (MIS, coloring, cuts, flows, Hamiltonian) BicliqueCover, MaximalIS, PaintShop ~12
2nd Packing/covering (set cover, bin packing, knapsack) Knapsack, BinPacking, BMF ~4
3rd Scheduling (flow shop, job shop, multiprocessor) StaffScheduling ~3

Does this order make sense? Should a different domain go first?

Related issues

cc @GiggleLiu @isPANN

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions