[Model] PrizeCollectingSteinerForest

[zhangjieqingithub]

Motivation

The catalog already has Steiner-tree models, but it does not have the biology-facing prize-collecting Steiner forest variant used to recover multiple pathway components at once.

This model is useful because it:

• generalizes prize-collecting Steiner tree from one connected tree to a forest,
• keeps the paper's node-prize / edge-cost objective directly in the model,
• separates the biological model from the artificial-root trick, which should live in a reduction rule rather than in the base problem definition.

Associated rule:

• [Rule] PrizeCollectingSteinerForest to SteinerTree #1027: PrizeCollectingSteinerForest -> SteinerTree

Definition

Name: PrizeCollectingSteinerForest
Reference:

• Nurcan Tuncbag et al., "Simultaneous Reconstruction of Multiple Signaling Pathways via the Prize-Collecting Steiner Forest Problem," Journal of Computational Biology 20(2):124-136, 2013. https://doi.org/10.1089/cmb.2012.0092
• Nurcan Tuncbag et al., "Simultaneous Reconstruction of Multiple Signaling Pathways via the Prize-Collecting Steiner Forest Problem," RECOMB 2012, LNBI 7262, pp. 287-301, 2012. https://doi.org/10.1007/978-3-642-29627-7_31

For a network
G = (V, E, c, p)
with nonnegative edge costs c(e) >= 0, nonnegative vertex prizes p(v) >= 0, and parameters beta >= 0, omega >= 0, find a forest subgraph
F = (V_F, E_F)
minimizing
beta * sum_{v notin V_F} p(v) + sum_{e in E_F} c(e) + omega * kappa(F),
where kappa(F) is the number of tree components of F.

Important conventions for this proposal:

• singleton vertices are allowed as one-vertex tree components,
• the empty forest is feasible,
• at the paper level, the input network may be directed or undirected,
• in the directed case, "forest" means acyclic after forgetting edge directions.

So this is a minimization problem.

Variables

Let n = |V| and m = |E|.

• Count: n + m binary variables
• Per-variable domain: {0,1}
• Meaning:
  • x_v = 1 iff vertex v belongs to V_F
  • y_e = 1 iff edge or arc e belongs to E_F

A configuration is feasible iff the selected edges are incident only to selected vertices and the selected subgraph is a forest. Singleton selected vertices are allowed.

Schema (data type)

Type name: PrizeCollectingSteinerForest

Paper-level variants:

• undirected networks
• directed networks

Recommended first concrete repo variant:

• SimpleGraph initially
• weight types i32 and f64
• directed-network support can be added later as a variant extension

Field	Type	Description
graph	G	The underlying network
vertex_prizes	Vec<W>	Vertex prizes p : V -> R_{>= 0}
edge_costs	Vec<W>	Edge or arc costs c : E -> R_{>= 0}
beta	W	Tradeoff coefficient on omitted prizes
omega	W	Cost per tree component

Complexity

A conservative exact baseline is brute-force over vertex selections and edge selections, checking whether the chosen subgraph is a forest and evaluating the objective.

This gives a conservative worst-case bound
O(2^(num_vertices + num_edges) * poly(num_vertices + num_edges))

so the registry complexity string should be
2^(num_vertices + num_edges).

I have not verified a sharper exact worst-case bound for this specific paper-style PCSF variant, so the proposal should use the conservative baseline above.

References for the model and its practical solver context:

• https://doi.org/10.1089/cmb.2012.0092
• https://doi.org/10.1007/978-3-642-29627-7_31

Extra Remark

This is not the standard demand-pair penalty version of PCSF.

The intended model is the biology-paper variant with:

• node prizes,
• edge costs,
• an explicit component penalty omega * kappa(F).

The artificial root is not part of the base model. It belongs in the companion reduction rule.

Reduction Rule Crossref

• [Rule] PrizeCollectingSteinerForest to SteinerTree #1027

How to solve

• It can be solved by brute force.
• It can be reduced to SteinerTree on an augmented graph via [Rule] PrizeCollectingSteinerForest to SteinerTree #1027 ([Rule] PrizeCollectingSteinerForest to SteinerTree).
• Other, refer to ...

Example Instance

Take the undirected path
0 - 1 - 2
with:

• edge costs
  • c(0,1) = 1
  • c(1,2) = 6
• vertex prizes
  • p(0) = 5
  • p(1) = 2
  • p(2) = 5
• beta = 1
• omega = 2

Expected Outcome

An optimal forest is:

• V_F = {0,1,2}
• E_F = {(0,1)}

So the forest has two components:

• the tree on {0,1}
• the singleton tree {2}

Its objective value is:

• omitted-prize term: 0
• edge-cost term: 1
• component term: 2 * 2 = 4

Total:
1 + 4 = 5

This is better than:

• the full path {(0,1),(1,2)}, which costs 1 + 6 + 2 = 9
• three singleton vertices, which cost 0 + 0 + 3 * 2 = 6
• the empty forest, which costs 5 + 2 + 5 = 12

So the optimum is 5.

BibTeX

@article{TuncbagEtAl2013PCSF,
  author  = {Nurcan Tuncbag and Alfredo Braunstein and Andrea Pagnani and Shao-Shan Carol Huang and Jennifer Chayes and Christian Borgs and Riccardo Zecchina and Ernest Fraenkel},
  title   = {Simultaneous Reconstruction of Multiple Signaling Pathways via the Prize-Collecting Steiner Forest Problem},
  journal = {Journal of Computational Biology},
  volume  = {20},
  number  = {2},
  pages   = {124--136},
  year    = {2013},
  doi     = {10.1089/cmb.2012.0092},
  url     = {https://doi.org/10.1089/cmb.2012.0092}
}

@inproceedings{TuncbagEtAl2012RECOMB,
  author    = {Nurcan Tuncbag and Alfredo Braunstein and Andrea Pagnani and Shao-Shan Carol Huang and Jennifer Chayes and Christian Borgs and Riccardo Zecchina and Ernest Fraenkel},
  title     = {Simultaneous Reconstruction of Multiple Signaling Pathways via the Prize-Collecting Steiner Forest Problem},
  booktitle = {Research in Computational Molecular Biology (RECOMB 2012)},
  series    = {Lecture Notes in Bioinformatics},
  volume    = {7262},
  pages     = {287--301},
  year      = {2012},
  publisher = {Springer},
  doi       = {10.1007/978-3-642-29627-7_31},
  url       = {https://doi.org/10.1007/978-3-642-29627-7_31}
}

[isPANN]

Issue Quality Check — Model

Check	Result	Details
Usefulness	Pass	Novel problem (pred show PrizeCollectingSteinerForest returns Unknown); concrete companion rule #1027 links to existing SteinerTree
Non-trivial	Pass	Distinct from SteinerTree: multiple-component forest objective with node prizes, edge costs, and explicit component penalty omega * kappa(F); not a variant of an existing problem
Correctness	Pass	Tuncbag et al. (2013, J. Comp. Biol.) confirmed; objective form beta * sum_omitted_prizes + sum_edge_costs + omega * kappa(F) matches paper; worked-example arithmetic verified
Well-written	Pass	All template sections present and substantive; example is concrete, multiple suboptimal alternatives ruled out by arithmetic

Overall: 4 passed, 0 failed, 0 warnings

---

Usefulness

• pred show PrizeCollectingSteinerForest returns "Unknown problem", so the proposed model does not collide with anything in the catalog.
• The SteinerTree model already exists (SteinerTree/SimpleGraph/{One,i32}), and the issue cleanly separates the biology variant (node prizes + edge costs + per-component penalty) from the existing tree formulation. The companion rule [Rule] PrizeCollectingSteinerForest to SteinerTree #1027 [Rule] PrizeCollectingSteinerForest to SteinerTree is filed and labeled rule, so the new node will not be an orphan in the reduction graph.
• Motivation is concrete: simultaneous reconstruction of multiple signaling pathways in interactome analysis (OmicsIntegrator2-style workflows). This is a genuine biological use case rather than a synthetic puzzle.
• How to solve checks both brute force and reduction to SteinerTree via [Rule] PrizeCollectingSteinerForest to SteinerTree #1027, so there is at least one verifiable solver path.

Non-trivial

• The model differs from SteinerTree in three structural ways:
  1. Vertex prizes p(v), not just edge weights.
  2. Forest (multiple tree components) instead of a single tree, including singleton vertices and the empty forest as feasible.
  3. Per-component penalty omega * kappa(F) that explicitly trades component count against omitted prizes.
• These changes alter both the feasibility region (forests, not connected trees) and the objective (three additive terms instead of one), so this is not isomorphic to SteinerTree and not a thin variant of it.
• The author explicitly chose not to bake the "artificial root" trick into the base model, leaving that gadget for the companion reduction rule — a clean modeling decision.

Correctness

References verified:

• Tuncbag et al., J. Comp. Biol. 20(2):124-136, 2013, DOI 10.1089/cmb.2012.0092 — confirmed via PubMed PMID 23383998 (authors, venue, year match).
• Tuncbag et al., RECOMB 2012, LNBI 7262, pp. 287-301, DOI 10.1007/978-3-642-29627-7_31 — confirmed via dblp + Springer.
• Web search corroborates the objective: "κ is the number of connected components, β controls the relative weight of the node prizes, and ω controls the cost of adding an additional tree". This matches the issue's
  beta * sum_{v notin V_F} p(v) + sum_{e in E_F} c(e) + omega * kappa(F).
• Worked example checked by hand. Path 0 - 1 - 2, costs c(0,1)=1, c(1,2)=6, prizes 5, 2, 5, beta=1, omega=2:
  • Proposed optimum V_F={0,1,2}, E_F={(0,1)}, 2 components: 0 + 1 + 2*2 = 5 ✓
  • Full path: 0 + 7 + 2 = 9 ✓
  • Three singletons (E_F=∅): 0 + 0 + 6 = 6 ✓
  • Empty forest: 12 + 0 + 0 = 12 ✓
  • Cross-check (not in issue): V_F={0,1}, E_F={(0,1)} drops vertex 2 → 5 + 1 + 2 = 8; V_F={1,2}, E_F={(1,2)} → 5 + 6 + 2 = 13. Both are suboptimal, so 5 is genuinely optimal.
• Complexity claim 2^(num_vertices + num_edges) is a conservative upper bound (enumerate vertex × edge subsets, check forest, evaluate objective). The issue is upfront that no sharper exact bound is asserted; this is acceptable for the registry.

Well-written

• All required Model sections present and substantive: Motivation, Name, Reference, Definition, Variables, Schema, Complexity, How to solve, Example Instance, Expected Outcome, BibTeX.
• Name PrizeCollectingSteinerForest follows project naming (matches existing SteinerTree naming convention).
• Schema fields (graph, vertex_prizes, edge_costs, beta, omega) align with the symbols in the Definition (p, c, beta, omega).
• Symbols defined before use: G = (V, E, c, p), n = |V|, m = |E|, kappa(F).
• Example exercises the core structure: at least two real component-vs-coverage tradeoffs (singletons vs trees) with multiple suboptimal feasible solutions, so a round-trip closed-loop test would actually catch a buggy implementation rather than passing vacuously.
• Edge-case conventions called out explicitly: singletons allowed, empty forest feasible, directed-vs-undirected scope deferred.

Recommendations

• For the first concrete repo variant, SimpleGraph + (One, i32, f64) weights is fine. When the directed variant is added later, kappa(F) and the "forest after forgetting directions" convention will need restating in the variant docs.
• Consider whether omega should be allowed to be 0 (reduces to plain prize-collecting Steiner forest without component penalty); the current Definition says omega >= 0, which permits this — worth confirming the reduction in [Rule] PrizeCollectingSteinerForest to SteinerTree #1027 handles omega = 0 gracefully.
• The complexity string 2^(num_vertices + num_edges) is correct but loose; a tighter bound from the Steiner-forest literature (e.g., Dreyfus-Wagner-style DP after the artificial-root reduction) could be substituted once the reduction is implemented, but the conservative baseline is acceptable for a first pass as the issue acknowledges.

[isPANN]

/review-structural — commit b3d6fbd (post-impl, code-quality + bug sweep)

Verdict: pass — PrizeCollectingSteinerForest model is mathematically correct, structurally complete, and faithful to issue #1026; only minor cleanup nits found.

Issue compliance

• Mathematical definition matches issue: yes — config = [x_v...; y_e...] (length n + m), feasibility is "selected edges only between selected vertices" + acyclic, singleton selected vertices counted in kappa, objective beta * omitted_prizes + edge_costs + omega * kappa matches the issue verbatim.
• Schema fields match: yes — graph, vertex_prizes, edge_costs, beta, omega with types and descriptions matching the issue's schema table. ProblemSizeFieldEntry exposes num_vertices and num_edges, consistent with the declared complexity 2^(num_vertices + num_edges).
• Canonical example: ok — issue's path 0-1-2 with c=(1,6), p=(5,2,5), beta=1, omega=2, optimum [1,1,1,1,0] → value 5 registered via canonical_model_example_specs() and wired through src/models/graph/mod.rs. The brute-force test and paper figure both reproduce value 5.

Structural checklist (model)

All 16 checks pass: file src/models/graph/prize_collecting_steiner_forest.rs present; two inventory::submit! blocks (schema + size fields); Serialize/Deserialize with proper bound; Problem impl with Value = Min<W::Sum>; #[cfg(test)] #[path = ...] link to src/unit_tests/models/graph/prize_collecting_steiner_forest.rs; 13 fn test_* (well above the >=3 threshold); registered in src/models/graph/mod.rs (pub(crate) mod, pub use, and canonical_model_example_specs() extension); declare_variants! registers (SimpleGraph, i32) as default and (SimpleGraph, f64); CLI flags --vertex-prizes, --edge-costs, --beta, --omega added to CreateArgs and to flag_map() (kebab-case matches schema field names; no naming collisions with existing flags); parse_field_value() already handles Vec<i32>, Vec<f64>, i32, f64 so no new dispatcher needed; paper display-name and problem-def blocks present with a worked example breakdown, CeTZ figure, and Crossref-verified BibTeX for both Tuncbag et al. papers.

Semantic correctness (spot-checked, no cargo test run per instructions)

• BFS cycle detection uses parent_edge[u] == Some(edge_idx) to skip the discovery edge — correct for undirected SimpleGraph (start vertex's parent_edge is None, so the start handles itself, and a parallel edge to the parent would correctly trigger the back-edge branch).
• kappa counted once per BFS root over selected vertices, so isolated selected vertices contribute exactly one singleton component each — matches the issue's "singleton selected vertices are allowed" convention.
• Objective math uses additive omega accumulation rather than kappa.try_into() because NumericSize doesn't require From<usize> — sound; a cleaner alternative (From<usize>) is just a future ergonomics improvement, not a defect.
• is_valid_solution() and evaluate() share is_feasible_forest-equivalent logic but evaluate inlines its own copy. The duplication is intentional (the inlined version tracks kappa along the way) and the standalone helper is used only by is_valid_solution. Acceptable; mild DRY nit.

Findings

• Blockers (correctness): none
• Nits (quality/HCI):
  • total_selected_vertices is accumulated inside the BFS loop but never read; the trailing let _ = total_selected_vertices; only silences the unused-variable warning. Either drop the accumulator and comp_vertices tracking, or use it (e.g., as an additional sanity check that total_selected_vertices == sum of x_v).
  • parent_edge: Vec<Option<usize>> is reallocated to size n for every connected component inside the outer for start in 0..n loop. For sparse forests with many components this is O(n * kappa) allocations. Hoist it once before the outer loop and reuse (resetting only the visited slots) for a minor speedup. Not load-bearing for any 5-second test budget.
  • The standalone is_feasible_forest helper duplicates the feasibility logic embedded in evaluate. Consider extracting a single shared helper that returns (feasible, kappa) so both code paths share one source of truth. (Pure DRY/maintenance nit — current code is correct.)
  • Paper body prose at line 1248-1249 references hard-coded values ("two components", "$kappa(F) = 2$", "$(5+2+5)$", "$3 omega = 6$") even though the surrounding figure machinery loads the canonical example dynamically. If the canonical instance ever changes, the prose will silently desync from the rendered numbers. Either inline the dynamic values everywhere (#omitted-verts.len(), #vertex-prizes.sum(), #(3 * omega), etc.) or leave a comment that the prose is hard-coded for issue [Model] PrizeCollectingSteinerForest #1026 only.
  • #[reduction]-side rule (issue [Rule] PrizeCollectingSteinerForest to SteinerTree #1027, PrizeCollectingSteinerForest -> SteinerTree) is explicitly out of scope here — verified no src/rules/prizecollectingsteinerforest_* file exists in this commit. Good.