d4-journals-geb-2019-0108

· ? (d4-journals-geb-2019-0108)

no mirror
paperd4-journals-geb-2019-0108
authors—
venue?
filed underunclassified
judged bygpt-6-luna / xhigh (triple__luna__xhigh__c6r1)
judge confidencehigh
authors would recognise ityes

Why no mirror

The paper’s named results characterize stochastic stability and selected allocations, but give no algorithm, complexity bound, hardness result, or solver-based formulation. The proposed type-mass minimax problem is a plausible new computational question inspired by Theorem 5.3; deriving it from an analytic characterization does not make that theorem computational.

fails bit a — no named computational result to mirror

What the mirror covers

The proposed minimax question reflects the selection criterion in Theorem 5.3; it leaves aside Theorem 5.8’s dispersed-core result, Theorem 4.3’s stochastic-potential characterization, and the heterogeneous-utility and empty-core analyses.

Open questions for a prover

The case FOR (proponent)

I find no qualifying anchor in this paper: it has no numbered result saying a computational problem is in P, NP-hard, FPT, or otherwise classifying its complexity.

The closest result is Theorem 5.3, proved here: when the strict core is nonempty, an allocation is stochastically stable if and only if it is in \(\min\Omega_\Delta^*\)—the strict-core allocations that minimize the richest player’s claim. Theorem 5.8, also proved here, says that with a nonempty strict dispersed core, the limiting stationary distribution places probability \(1\) on \(\min\Omega_\Delta^*\), though not every allocation in that set must be stochastically stable. These are selection results about a finite-player dynamic, not algorithmic or complexity results. Theorem 4.3 gives a stochastic-potential characterization and cites Young and Sawa; it is not a complexity result either.

A plausible high-multiplicity setting for a *future* version would be a large cooperative whose members fall into finitely many complete types—sharing utility, reservation value, and coalition-relevant characteristics. Mass would represent each type’s population share; decisions would allocate that mass among coalition compositions and surplus claims. But the paper supplies neither that continuous model nor a computational question about it. Its logit noise perturbs transitions among finite states; it does not make the population continuous.

So the positive intuition is available, but no continuous problem can be honestly presented here as a mirror of a qualifying named computational result. My weakest point is the whole case: the paper’s results are analytic stochastic-stability characterizations, outside the programme’s computational scope.

The case AGAINST (opponent, writing after the proponent)

The strongest mirror is Theorem 5.3. It gives an exact optimization target: in a strict core, stochastically stable allocations are precisely those minimizing the richest player’s claim. That makes “compute a stochastically stable allocation” a natural algorithmic problem, even though Sawa does not analyze its complexity.

A plausible high multiplicity version is a large cooperative with finitely many complete player types: members of a type share utility, reservation value, and coalition relevant characteristics. Let \(\mu_t\) be the mass of type \(t\), and let \(V(\alpha)\) give the surplus from a coalition with type masses \(\alpha\), where \(0\leq \alpha_t\leq\mu_t\). If type \(t\) members receive claim \(x_t\), the core constraints include \(\sum_t \alpha_t x_t\geq V(\alpha)\) for every coalition mass vector \(\alpha\), alongside feasibility for the whole society. The continuous mirror of Theorem 5.3 is to minimize \(\max_t x_t\) over this core. This is a computational question about the population itself: \(\mu\) is the input society, and coalition deviations are masses. With a compact representation of \(V\), checking a candidate allocation leads directly to the pricing problem \(\max_{\alpha\leq\mu}(V(\alpha)-\sum_t\alpha_t x_t)\). Its tractability, approximation, or parameterization by support size and input length is worth investigating.

Theorem 5.8 supplies a related question for dispersed cores. A population can be partitioned into coalition masses, represented by a distribution over coalition type compositions. One can ask how to compute allocations in the guaranteed stable set, or use the stochastic potential to distinguish stable states within it. Theorem 4.3 makes that latter objective explicit: minimize the total transition cost of a directed tree rooted at the state. In a mass model, the transition cost has a natural aggregate form, such as \(\int [u_t(x_t)-u_t(y_t)]_+\,d\alpha_t\) for a mass deviation from claims \(x\) to \(y\). Extending the tree characterization to an aggregate state space would require specifying the mass-level dynamics; that difficulty is part of the computational question, not a reason to dismiss it.

The proposed setting must impose structure on coalition values: with the paper’s unrestricted characteristic function, a player’s full coalition signature may make nearly every player a different type. Large membership organizations or other cooperative populations with repeated roles and composition-based surplus provide a credible regime. The model would also need a deliberate scaling of coalition moves and logit resistance as population mass replaces individual counts. Those are substantive modeling choices, but the programme explicitly allows co-modifications forced by continuization.

The case has a real limitation: the paper proves no complexity bound, and a requirement that every mirror reproduce an already-studied complexity theorem would rule it out. But under the programme’s stated aim of asking computational questions, Theorem 5.3 provides more than a loose analogy: it supplies the selection objective whose continuous optimization and pricing complexity can be studied.

The adversarial triple: the proponent anchors on up to three named results; the opponent sees that case and must defeat every anchor; the judge decides which case convinced it. These are the pipeline’s own outputs, generated by tools/triple_run.py — no human edited them. The paper’s own text is not reproduced here beyond the quoted statement above.