[Model] KthLargestMTuple

[isPANN]

Motivation

K-th LARGEST m-TUPLE (P148) from Garey & Johnson, A3 SP21. This problem generalizes the K-th LARGEST SUBSET problem from subsets of a single set to m-tuples drawn from a Cartesian product of m sets. It asks whether at least K distinct m-tuples have total size at least B. Like K-th LARGEST SUBSET, it is not known to be in NP and was shown to be PP-complete under polynomial-time Turing reductions (Haase & Kiefer, 2016). It is solvable in polynomial time for fixed m and in pseudo-polynomial time in general.

Associated reduction rules:

• As target: R86 (PARTITION -> K-th LARGEST m-TUPLE)

Definition

Name: KthLargestMTuple

Reference: Garey & Johnson, Computers and Intractability, A3 SP21

Mathematical definition:

INSTANCE: Sets X_1, X_2, ..., X_m ⊆ Z^+, a size s(x) ∈ Z^+ for each x ∈ X_i, 1 ≤ i ≤ m, and positive integers K and B.
QUESTION: Are there K or more distinct m-tuples (x_1, x_2, ..., x_m) in X_1 × X_2 × ... × X_m for which Σ_{i=1}^{m} s(x_i) ≥ B?

Variables

• Count: m (one variable per coordinate of the tuple)
• Per-variable domain: variable i ranges over {0, 1, ..., |X_i| - 1}, indexing elements in X_i
• Meaning: Each configuration (j_1, j_2, ..., j_m) selects elements x_{j_1} ∈ X_1, x_{j_2} ∈ X_2, ..., x_{j_m} ∈ X_m, defining one m-tuple. The problem counts how many such m-tuples satisfy Σ_{i=1}^{m} s(x_{j_i}) ≥ B and checks whether this count is at least K. This is a counting problem using type Value = Sum<u64>, where each configuration contributes Sum(1) if the tuple's total size ≥ B and Sum(0) otherwise. The brute-force aggregate gives Sum(count), which is compared against K externally.

Schema (data type)

Type name: KthLargestMTuple
Variants: none (no type parameters; sizes are plain positive integers)

Field	Type	Description
sets	Vec<Vec<u64>>	The m sets X_1, ..., X_m, each containing positive integer sizes
k	u64	Threshold K — number of distinct m-tuples required
bound	u64	Lower bound B on the sum of sizes in each m-tuple

Complexity

• Best known exact algorithm: The problem is PP-complete under polynomial-time Turing reductions (Haase & Kiefer, 2016). For fixed m, the number of m-tuples is |X_1| · |X_2| · ... · |X_m|, and brute-force enumeration runs in O(Π|X_i| · m) time. The pseudo-polynomial algorithm of Johnson & Mizoguchi (1978) runs in time polynomial in K, Σ|X_i|, and log Σ s(x). For the binary case (m = 2, "selecting the K-th element in X + Y"), the problem is solvable in O(n log n) time (Johnson & Mizoguchi, 1978).
• Concrete complexity expression: total_tuples * num_sets, where total_tuples = Π|X_i| and num_sets = m.

Specialization

Not known to be in NP. The K-th LARGEST m-TUPLE problem is not a standard NP decision problem because a "yes" certificate would need to exhibit K m-tuples, and K can be exponentially large in the input size. The problem is PP-complete under polynomial-time Turing reductions (Haase & Kiefer, 2016), placing it strictly above NP in the complexity hierarchy (under standard assumptions). If it were in NP, the polynomial hierarchy would collapse to P^NP.

Note: The problem is solvable in polynomial time for fixed m, because the total number of m-tuples is polynomial when m is constant. The PP-completeness arises when m is part of the input.

Extra Remark

Full book text:

INSTANCE: Sets X_1,X_2,...,X_m ⊆ Z^+, a size s(x) ∈ Z^+ for each x ∈ X_i, 1 ≤ i ≤ m, and positive integers K and B.
QUESTION: Are there K or more distinct m-tuples (x_1,x_2,...,x_m) in X_1×X_2×···×X_m for which Σ_{i=1}^{m} s(x_i) ≥ B?
Reference: [Johnson and Mizoguchi, 1978]. Transformation from PARTITION.
Comment: Not known to be in NP. Solvable in polynomial time for fixed m, and in pseudo-polynomial time in general (polynomial in K, Σ|X_i|, and log Σs(x)). The corresponding enumeration problem is #P-complete.

How to solve

• It can be solved by (existing) bruteforce. (Enumerate all m-tuples in X_1 × ... × X_m; each configuration returns Sum(1) if sum ≥ B, Sum(0) otherwise; aggregate gives total count; check count ≥ K.)
• It can be solved by reducing to integer programming.
• Other: For fixed m, enumerate all Π|X_i| tuples in polynomial time. For general m, use dynamic programming on partial sums across the m sets.

Example Instance

Input:
m = 3 sets:

• X_1 = {2, 5, 8} (3 elements)
• X_2 = {3, 6} (2 elements)
• X_3 = {1, 4, 7} (3 elements)

B = 12, K = 14

Total m-tuples: 3 × 2 × 3 = 18

Enumeration of all m-tuples with sum ≥ 12:

x_1	x_2	x_3	Sum	≥ 12?
2	3	1	6	No
2	3	4	9	No
2	3	7	12	Yes
2	6	1	9	No
2	6	4	12	Yes
2	6	7	15	Yes
5	3	1	9	No
5	3	4	12	Yes
5	3	7	15	Yes
5	6	1	12	Yes
5	6	4	15	Yes
5	6	7	18	Yes
8	3	1	12	Yes
8	3	4	15	Yes
8	3	7	18	Yes
8	6	1	15	Yes
8	6	4	18	Yes
8	6	7	21	Yes

Feasible m-tuples (sum ≥ 12): 14 tuples.
Since 14 ≥ K = 14, the answer is YES (boundary case — K = 15 would flip to NO).

References

• [Johnson and Mizoguchi, 1978]: [Johnson1978a] Donald B. Johnson and Takumi Mizoguchi (1978). "Selecting the $K$th element in $X+Y$ and $X_1+X_2+\cdots+X_m$". SIAM Journal on Computing 7, pp. 147-153.
• [Haase and Kiefer, 2016]: [Haase2016] Christoph Haase and Stefan Kiefer (2016). "The complexity of the Kth largest subset problem and related problems". Information Processing Letters 116(2), pp. 111-115.

[zazabap]

Issue Quality Check — Model

Check	Result	Details
Usefulness	❌ Fail	PP-complete problem does not fit the project's NP-hard problem framework; counting/threshold semantics incompatible with trait hierarchy
Non-trivial	✅ Pass	Distinct from all existing problems
Correctness	⚠️ Warn	References mostly verified, but author first name is wrong for Johnson & Mizoguchi 1978
Well-written	⚠️ Warn	Example is correct; trait-fit concerns not addressed

Overall: 1 passed, 1 failed, 2 warnings

---

Usefulness

Same fundamental issue as #404 (KthLargestSubset). The project is a "Rust library for NP-hard problem reductions," but KthLargestMTuple is PP-complete (Haase & Kiefer, 2016), strictly above NP under standard assumptions.

The trait mismatch is the same: SatisfactionProblem::evaluate(config) -> bool evaluates a single m-tuple (whether its sum ≥ B), but the overall answer requires counting how many m-tuples satisfy the constraint and checking if the count ≥ K. No single configuration serves as a certificate. BruteForce::find_satisfying() returns a single satisfying config, which is meaningless for this counting/threshold problem.

Recommendation: Same as #404 — this problem requires a CountingProblem trait or equivalent that the project does not currently support. Consider removing from the backlog.

Non-trivial

The problem is genuinely distinct. It generalizes KthLargestSubset from subsets to Cartesian product tuples, with a different input structure (multiple sets rather than one).

Correctness

• Haase & Kiefer (2016): ✅ Confirmed. Same paper as [Model] KthLargestSubset #404 — "The Complexity of the Kth Largest Subset Problem and Related Problems," Information Processing Letters 116(2):111–115. The paper explicitly covers both the K-th Largest Subset and K-th Largest m-Tuple problems, proving both PP-complete.

• Johnson & Mizoguchi (1978): ✅ Paper confirmed: "Selecting the Kth Element in X + Y and X₁ + X₂ + ··· + Xₘ," SIAM Journal on Computing 7(2):147–153. However, the issue states the first author is "David B. Johnson" — the actual author is Donald B. Johnson. This should be corrected. ⚠️

• The claim about O(n log n) for the binary case (m = 2) is correct per the paper.

Well-written

Strengths:

• Complete and thorough with full G&J book text
• Excellent example with full 18-tuple enumeration table — verified correct (14 tuples with sum ≥ 12)
• Clear variable description and schema
• Good references section with bibliographic details

Issues:

• Author name error: "David B. Johnson" should be "Donald B. Johnson"
• Same trait-fit concern as [Model] KthLargestSubset #404: the issue acknowledges this is a decision/satisfaction problem but doesn't address how counting semantics would map to the project's per-config evaluate function
• The "How to solve" section's ILP claim ("Use integer variables to index each set, with a constraint on the sum") doesn't address the counting aspect — ILP finds one feasible tuple, not a count of K

[isPANN]

On Hold — Requires Architectural Support

Same as #404 (KthLargestSubset): this problem is PP-complete with counting threshold semantics that don't fit the current SatisfactionProblem trait. Blocked on new trait support for counting problems.

Moving to OnHold.

[isPANN]

Issue Quality Check — Model (Re-check)

Check	Result	Details
Usefulness	❌ Fail	PP-complete problem does not fit the project's NP-hard problem framework; counting/threshold semantics incompatible with trait hierarchy
Non-trivial	✅ Pass	Distinct from all 112 existing problems
Correctness	⚠️ Warn	Author name error: "David B. Johnson" → "Donald B. Johnson"; PP-completeness should specify "under poly-time Turing reductions"
Well-written	⚠️ Warn	ILP checkbox marked but no companion [Rule] KthLargestMTuple to ILP issue linked; example correct but K=8 is easy YES (far from threshold)

Overall: 1 passed, 1 failed, 2 warnings

Re-check of previous report (2026-03-12). Previously: 1 pass, 1 fail, 2 warnings → Now: same verdicts, additional details below.

---

Usefulness

❌ Fail — Same fundamental issue as previous check and #404.

The project is a "Rust library for NP-hard problem reductions," but KthLargestMTuple is PP-complete under polynomial-time Turing reductions (Haase & Kiefer, 2016). PP is strictly above NP under standard assumptions.

The trait mismatch remains unresolved:

• Problem::evaluate(config) evaluates a single m-tuple (whether its sum ≥ B), returning a bool
• But the decision problem asks: count how many m-tuples satisfy the constraint and check if count ≥ K
• No single configuration serves as a certificate — K can be exponentially large
• BruteForce::find_satisfying() returns one satisfying config, which is meaningless for counting/threshold semantics

The only planned reduction (R86: PARTITION → KthLargestMTuple) goes FROM an NP-hard problem TO a PP-complete one, which is the wrong direction for proving NP-hardness of the target. This reduction is expected (G&J lists it), but it demonstrates PP-completeness, not NP-completeness.

Blocked on: A CountingProblem trait or threshold-counting extension to the trait hierarchy.

Non-trivial

✅ Pass — The problem is genuinely distinct from all 112 existing problems. It generalizes KthLargestSubset (#404) from subsets of one set to Cartesian product tuples across m sets, with a different input structure (Vec<Vec<u64>> vs a single set).

Correctness

⚠️ Warn — References verified, but with minor issues.

Johnson & Mizoguchi (1978): ✅ Paper confirmed — "Selecting the Kth Element in X + Y and X₁ + X₂ + ··· + Xₘ," SIAM Journal on Computing 7(2):147–153. However, the first author is Donald B. Johnson, not "David B. Johnson" as stated in the issue. ⚠️

• O(n log n) for m=2: ✅ Confirmed
• Polynomial for fixed m: ✅ Confirmed
• Note: Frederickson & Johnson (1982) improved the m=2 case to O(n + k), but this doesn't affect the issue's claims

Haase & Kiefer (2016): ✅ Paper confirmed — "The Complexity of the Kth Largest Subset Problem and Related Problems," Information Processing Letters 116(2):111–115. PP-completeness result is Theorem 3, explicitly covering the K-th Largest m-Tuple problem. The issue should note this is under polynomial-time Turing reductions (not many-one reductions).

Python verification of the example:

Total m-tuples: 18
Feasible (sum ≥ 12): 14
Non-feasible: 4
Answer: YES (14 ≥ 8)

All 18 tuples and sums match the issue's enumeration table exactly. ✅

Well-written

⚠️ Warn — Mostly well-structured, but several issues:

1. ILP checkbox without companion issue: The "How to solve" section checks ILP, but no [Rule] KthLargestMTuple to ILP issue exists. Moreover, the ILP claim is dubious — ILP finds one feasible tuple, but cannot count K of them without auxiliary enumeration. ⚠️

2. Example quality: The example is correct and thorough (full 18-tuple table), but K=8 is well below the actual feasible count of 14. A more discriminating example would use K=14 (boundary YES) or K=15 (boundary NO) to test edge behavior. The current K=8 makes it trivially YES.

3. Complexity section: Provides prose descriptions but lacks a concrete complexity expression in terms of problem parameters (e.g., O(Π|X_i| * m)). The declare_variants! macro needs a specific formula string.

4. Author name: "David B. Johnson" → "Donald B. Johnson" (factual error)

5. Trait-fit not addressed: The issue doesn't discuss how counting semantics would map to the project's per-config evaluate function

Recommendations

• Fix author name: Donald B. Johnson, not David
• Specify PP-completeness is under polynomial-time Turing reductions
• Add a concrete complexity string for declare_variants!
• Consider whether this issue should remain on hold until a counting/threshold trait is designed

[isPANN]

Fix-issue changelog

• Fixed author name: "David B. Johnson" → "Donald B. Johnson" (References)
• Added precision: PP-completeness is "under polynomial-time Turing reductions" (Motivation, Specialization)
• Updated Variables section: from "satisfaction (decision) problem" to counting problem with type Value = Sum<u64> semantics
• Added concrete complexity expression: total_tuples * num_sets (Complexity)
• Fixed "NP-hardness arises" → "PP-completeness arises" (Specialization)
• Unchecked ILP in "How to solve" — counting problems can't be solved via ILP
• Updated brute-force description with Sum(1)/Sum(0) aggregate semantics (How to solve)
• Changed example K from 8 (easy YES) to 14 (boundary YES — K=15 flips to NO)

Applied by /fix-issue.