| paper | d4-conf-atal-2023-0452 |
| authors | — |
| venue | ? |
| filed under | unclassified |
| judged by | gpt-6-luna / xhigh (triple__luna__xhigh__c6r1) |
| judge confidence | high |
| authors would recognise it | no |
The paper presents pref-MCTS as an algorithm and evaluates it empirically, but contains no numbered theorem, lemma, corollary, or proposition asserting an algorithmic guarantee or hardness result. The proposed many-user objective would change single-user preference-guided scheduling into collective aggregation, so it is not a continuous analogue anchored by a result in this paper.
fails bit a — no named computational result to mirror
No named computational theorem is present; the pref-MCTS algorithm and its oracle and user-study evaluations are left without a population mirror.
I can’t make a compliant positive case from this paper: it has no numbered theorem, lemma, corollary, or proposition asserting a computational result. It describes pref-MCTS and Algorithm 1, then reports empirical results from an oracle evaluation and a 10-person user study. Those results are not complexity claims about intention scheduling or preference learning, so there is no qualifying anchor to quote and restate.
A plausible extension would apply a shared intention scheduler to many users: let each type encode a user’s preferences over trajectories, let \(\mu_t\) be that type’s population share, and choose a schedule to maximize population-weighted satisfaction. But this replaces the paper’s task—learning one user’s preferences to schedule one agent—with a group preference aggregation problem. The paper establishes no computational result for that problem, so it would be a new proposal, not a continuous mirror anchored in this paper.
The strongest case against a mirror is that there is no computational result here to mirror. The paper gives Algorithm 1 and reports empirical findings: pref-MCTS improves over baselines on a synthetic oracle, and all ten study participants preferred its generated trajectories to the initial batch. It gives no theorem or complexity analysis for a computational problem. Those findings depend on particular GPT generators, query budgets, and evaluations; they do not establish a discrete complexity claim that could be translated to societies given as distributions over types.
The best population version would give many users preference types, ask for comparisons over a shared set of trajectories, and choose a schedule maximizing population-weighted satisfaction, such as \(\sum_t \mu_t r_t(\tau)\). That is a coherent research question, but it changes the task. The paper learns one user’s preferences to schedule that user’s agent. If users get separate agents and schedules, the problem decomposes into individual runs. If they must share one schedule, the model needs a collective objective and a way to compare satisfaction across users—choices the paper does not make. Adding shared capacity or a pooled query budget could create further coupling, but would introduce an allocation problem of its own.
Pooling many users with the same preference and task could also improve preference estimates. That would treat them as repeated feedback sources, though, not as a continuous society whose computational problem is established by the paper. And if users differ in preferences, contexts, or feasible trajectories, the proposed types and aggregation rule become substantive new modeling choices.
So the negative case is strong against calling any of these a *mirror* of a result in this paper. It is weaker against the broader claim that a new continuous-population project could be worthwhile: collective scheduling with shared resources might be. But that would be a new computational question inspired by pref-MCTS, not the continuization of a computational result this paper proves.
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.