pith. machine review for the scientific record. sign in

arxiv: 2605.05949 · v2 · submitted 2026-05-07 · 💻 cs.AI · cs.SE

Recognition: no theorem link

MAS-Algorithm: A Workflow for Solving Algorithmic Programming Problems with a Multi-Agent System

Yuliang Xu , Xiang Xu , Yao Wan , Hu Wei , Tong Jia
Authors on Pith no claims yet

Pith reviewed 2026-05-11 01:04 UTC · model grok-4.3

classification 💻 cs.AI cs.SE
keywords multi-agent systemalgorithmic problem solvingAI codingworkflowstructured reasoningacceptance rateQwen models
0
0 comments X

The pith

Multi-agent workflow decomposes algorithmic coding into modular stages and raises model acceptance rates by 6.48 percent on average.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents MAS-Algorithm, a multi-agent workflow that breaks algorithmic problem solving into distinct stages modeled on how competitive programmers work. This setup lets separate agents handle planning, coding, testing, and debugging with tool integration and coordination, aiming to improve structured reasoning without changing the underlying model. Experiments across Qwen series models on a self-built benchmark show a 6.48 percent average lift in acceptance rate, compared with only 0.89 percent from parameter-efficient fine-tuning on identical data. Gains also appear on LiveCodeBench-Pro, and ablation tests indicate individual agents can add up to 27.7 percent improvement.

Core claim

MAS-Algorithm is a systematic multi-agent workflow for algorithmic problem solving that decomposes the end-to-end process into modular stages, enabling structured reasoning, tool integration, and flexible agent coordination. The framework delivers consistent gains, including a 6.48 percent average increase in acceptance rate on a self-constructed benchmark and 4.72 percent on LiveCodeBench-Pro, while outperforming parameter-efficient fine-tuning and supporting detailed error-pattern analysis.

What carries the argument

The multi-agent workflow that decomposes the solving process into modular stages for coordination, reasoning, and tool use.

Load-bearing premise

The observed gains come from the modular multi-agent decomposition and coordination rather than from prompt details or benchmark-specific artifacts.

What would settle it

A controlled test in which a single prompt that lists the same stages without separate agents produces acceptance-rate gains equal to or larger than the multi-agent version on the same benchmark.

Figures

Figures reproduced from arXiv: 2605.05949 by Hu Wei, Tong Jia, Xiang Xu, Yao Wan, Yuliang Xu.

Figure 1
Figure 1. Figure 1: Structure diagram of our five Agent components. view at source ↗
Figure 2
Figure 2. Figure 2: The execution process of the MAS-Algorithm workflow. view at source ↗
Figure 3
Figure 3. Figure 3: Evolution of AC rate across iterative refinement and transition statistics. view at source ↗
Figure 4
Figure 4. Figure 4: Statistics of Chain-of-Thought (CoT) length across iterations. “Base” refers to a distilled view at source ↗
Figure 5
Figure 5. Figure 5: The distribution of different question types in the training and test sets. view at source ↗
read the original abstract

Algorithmic problem solving serves as a rigorous testbed for evaluating structured reasoning in AI coding systems, as it directly reflects a model's ability to perform structured reasoning in complex scenarios. Existing approaches predominantly rely on model-centric strategies, such as architectural modifications and data scaling, which are costly and offer limited interpretability. Alternative methods leveraging external tools or prompting techniques (e.g., chain-of-thought) are often fragmented and lack a unified framework. In this paper, we propose MAS-Algorithm, a systematic multi-agent workflow for algorithmic problem solving inspired by the practices of competitive programmers and algorithm engineers. Our framework decomposes the end-to-end solving process into modular stages, enabling structured reasoning, tool integration, and flexible coordination among agents. The design emphasizes both rigor and extensibility, allowing it to generalize across diverse problem types. Experimental results on a self-constructed benchmark demonstrate consistent improvements across multiple Qwen series models, achieving an average gain of 6.48% in acceptance rate. In contrast, parameter-efficient fine-tuning on the same data yields only a marginal improvement of 0.89%. We further observe a 4.72% gain on LiveCodeBench-Pro, along with consistent improvements across additional accuracy and efficiency metrics. Beyond performance gains, we conduct comprehensive analyses to better understand the reasoning process within the workflow, including error patterns and cross-scenario behaviors. We further perform customized replacement and ablation studies to explore the upper bound of the framework, showing that individual agents can contribute improvements of up to 27.7%. These results highlight the strong potential of MAS-Algorithm for advancing AI-driven algorithmic reasoning.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 1 minor

Summary. The paper introduces MAS-Algorithm, a multi-agent workflow that decomposes algorithmic problem solving into modular stages (inspired by competitive programming practices) with specialized agents for reasoning, tool use, and coordination. It claims consistent performance gains on a self-constructed benchmark (average +6.48% acceptance rate across Qwen models, vs. +0.89% for parameter-efficient fine-tuning on the same data) and +4.72% on LiveCodeBench-Pro, supported by ablations, agent-replacement studies, and analyses of error patterns.

Significance. If the reported gains can be isolated to the multi-agent decomposition and coordination rather than aggregate prompt engineering or benchmark artifacts, the framework would offer a practical, interpretable alternative to model-centric scaling for structured coding tasks, with extensibility across problem types and potential for upper-bound analysis via agent contributions (up to 27.7% in replacements).

major comments (3)
  1. The central performance claims (6.48% acceptance-rate gain on the self-constructed benchmark and 4.72% on LiveCodeBench-Pro) rest on comparisons that do not include an explicit single-agent baseline in which all agent instructions, tool-use rules, and coordination protocols are concatenated into one monolithic prompt of comparable length and detail. Without this control, the delta cannot be attributed to modularity rather than prompt complexity; this issue is load-bearing for the claim that gains arise from the multi-agent architecture.
  2. The experimental results section provides no description of the self-constructed benchmark (problem distribution, difficulty calibration, or construction process), no error bars, and no statistical tests for the reported percentage gains. This prevents evaluation of whether the 6.48% average improvement is robust or benchmark-specific.
  3. The ablation and agent-replacement studies operate entirely within the multi-turn, multi-prompt regime; they do not test whether equivalent performance can be achieved by a single agent given the full set of decomposed instructions, leaving the contribution of coordination mechanisms unisolated.
minor comments (1)
  1. The abstract and results would benefit from explicit clarification of the exact acceptance-rate metric (e.g., pass@1 vs. pass@k) and how it is computed on the self-constructed benchmark.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive feedback on isolating the contributions of our multi-agent design. We address each major comment below and will revise the manuscript accordingly to strengthen the attribution of gains and provide additional experimental details.

read point-by-point responses

  1. Referee: The central performance claims (6.48% acceptance-rate gain on the self-constructed benchmark and 4.72% on LiveCodeBench-Pro) rest on comparisons that do not include an explicit single-agent baseline in which all agent instructions, tool-use rules, and coordination protocols are concatenated into one monolithic prompt of comparable length and detail. Without this control, the delta cannot be attributed to modularity rather than prompt complexity; this issue is load-bearing for the claim that gains arise from the multi-agent architecture.

    Authors: We agree this control would help isolate modularity effects. Our agent-replacement studies already show that specialized agents contribute up to 27.7% individually, which relies on the ability to apply targeted instructions and tool-use rules dynamically across turns—features that a single monolithic prompt cannot replicate without losing coherence or exceeding context limits. Nevertheless, we will add an explicit single-agent baseline using the concatenated instructions in the revised experiments to directly quantify the coordination benefit. revision: yes

  2. Referee: The experimental results section provides no description of the self-constructed benchmark (problem distribution, difficulty calibration, or construction process), no error bars, and no statistical tests for the reported percentage gains. This prevents evaluation of whether the 6.48% average improvement is robust or benchmark-specific.

    Authors: We will expand the revised manuscript with a full description of the benchmark: it comprises 300 algorithmic problems drawn from competitive programming sources (LeetCode, Codeforces, AtCoder), stratified by difficulty (easy/medium/hard) using official acceptance rates and solution complexity metrics. We will also report standard error bars across model runs and include statistical tests (paired t-tests with p-values) to confirm the robustness of the 6.48% and 4.72% gains. revision: yes

  3. Referee: The ablation and agent-replacement studies operate entirely within the multi-turn, multi-prompt regime; they do not test whether equivalent performance can be achieved by a single agent given the full set of decomposed instructions, leaving the contribution of coordination mechanisms unisolated.

    Authors: The ablations were designed to measure incremental contributions within the MAS-Algorithm workflow, where coordination enables iterative refinement not feasible in a single pass. We acknowledge the value of testing a single agent with the complete instruction set. We will add this comparison in the revised ablation section to further isolate the coordination mechanisms. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical workflow evaluation is self-contained

full rationale

The paper proposes MAS-Algorithm as a multi-agent workflow for algorithmic problem solving and supports its value through direct experimental measurements on a self-constructed benchmark and LiveCodeBench-Pro. Reported gains (6.48% average acceptance-rate improvement, 4.72% on LiveCodeBench-Pro) and ablation/replacement studies are obtained by running the system and comparing outputs against baselines; no equations, fitted parameters, or derivations are present that would make any claimed result equivalent to its inputs by construction. The framework description draws inspiration from competitive programming practices but does not rely on self-citations or imported uniqueness theorems to establish its core claims. Because the central results are externally falsifiable performance deltas rather than tautological restatements, the derivation chain contains no load-bearing circular steps.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The framework rests on the domain assumption that decomposing algorithmic reasoning into modular agent-coordinated stages produces better performance than monolithic approaches; no free parameters or invented entities are introduced in the abstract.

axioms (1)
  • domain assumption Decomposing the end-to-end algorithmic solving process into modular stages enables structured reasoning and flexible agent coordination that improves outcomes.
    This premise underpins the entire MAS-Algorithm design and is invoked to explain the reported gains.

pith-pipeline@v0.9.0 · 5599 in / 1259 out tokens · 59772 ms · 2026-05-11T01:04:03.928909+00:00 · methodology

Review history (2 revisions) →

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

133 extracted references · 2 canonical work pages · 2 internal anchors

  1. [1]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian...

    2021

  2. [2]

    Is your code generated by chatGPT really correct? rigorous evaluation of large language models for code generation

    Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and LINGMING ZHANG. Is your code generated by chatGPT really correct? rigorous evaluation of large language models for code generation. InThirty-seventh Conference on Neural Information Processing Systems, 2023

    2023

  3. [3]

    Program synthesis with large language models, 2021

    Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, and Charles Sutton. Program synthesis with large language models, 2021

    2021

  4. [4]

    Livecodebench: Holistic and contamination free evaluation of large language models for code, 2024

    Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Ar- mando Solar-Lezama, Koushik Sen, and Ion Stoica. Livecodebench: Holistic and contamination free evaluation of large language models for code, 2024

    2024

  5. [5]

    Livecodebench pro: How do olympiad medalists judge llms in competitive programming?, 2025

    Zihan Zheng, Zerui Cheng, Zeyu Shen, Shang Zhou, Kaiyuan Liu, Hansen He, Dongruixuan Li, Stanley Wei, Hangyi Hao, Jianzhu Yao, Peiyao Sheng, Zixuan Wang, Wenhao Chai, Aleksandra Korolova, Peter Henderson, Sanjeev Arora, Pramod Viswanath, Jingbo Shang, and Saining Xie. Livecodebench pro: How do olympiad medalists judge llms in competitive programming?, 2025

    2025

  6. [6]

    Codeelo: Benchmarking competition-level code generation of llms with human-comparable elo ratings, 2025

    Shanghaoran Quan, Jiaxi Yang, Bowen Yu, Bo Zheng, Dayiheng Liu, An Yang, Xuancheng Ren, Bofei Gao, Yibo Miao, Yunlong Feng, Zekun Wang, Jian Yang, Zeyu Cui, Yang Fan, Yichang Zhang, Binyuan Hui, and Junyang Lin. Codeelo: Benchmarking competition-level code generation of llms with human-comparable elo ratings, 2025

    2025

  7. [7]

    Competition-level code generation with alphacode.Science, 378(6624):1092–1097, 2022

    Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al. Competition-level code generation with alphacode.Science, 378(6624):1092–1097, 2022

    2022

  8. [8]

    X-coder: Advancing competitive programming with fully synthetic tasks, solutions, and tests, 2026

    Jie Wu, Haoling Li, Xin Zhang, Jiani Guo, Jane Luo, Steven Liu, Yangyu Huang, Ruihang Chu, Scarlett Li, and Yujiu Yang. X-coder: Advancing competitive programming with fully synthetic tasks, solutions, and tests, 2026

    2026

  9. [9]

    Structured chain-of-thought prompting for code generation, 2023

    Jia Li, Ge Li, Yongmin Li, and Zhi Jin. Structured chain-of-thought prompting for code generation, 2023

    2023

  10. [10]

    Ren-Biao Liu, Anqi Li, Chaoding Yang, Hui Sun, and Ming Li. Revisiting chain-of-thought in code generation: Do language models need to learn reasoning before coding? In Aarti Singh, Maryam Fazel, Daniel Hsu, Simon Lacoste-Julien, Felix Berkenkamp, Tegan Maharaj, Kiri 10 Wagstaff, and Jerry Zhu, editors,Proceedings of the 42nd International Conference on M...

    2025

  11. [11]

    Problem-solving guide: Predicting the algorithm tags and difficulty for competitive programming problems, 2024

    Juntae Kim, Eunjung Cho, and Dongbin Na. Problem-solving guide: Predicting the algorithm tags and difficulty for competitive programming problems, 2024

    2024

  12. [12]

    AS-LLM: When algorithm selection meets large language model, 2024

    Xingyu Wu, Yan Zhong, Jibin Wu, and KC Tan. AS-LLM: When algorithm selection meets large language model, 2024

    2024

  13. [13]

    Can language models solve olympiad programming?, 2024

    Quan Shi, Michael Tang, Karthik Narasimhan, and Shunyu Yao. Can language models solve olympiad programming?, 2024

    2024

  14. [14]

    Retrieval-augmented code generation: A survey with focus on repository-level approaches, 2026

    Yicheng Tao, Yao Qin, and Yepang Liu. Retrieval-augmented code generation: A survey with focus on repository-level approaches, 2026

    2026

  15. [15]

    Muntasir Adnan, Zhiwei Xu, and Carlos C. N. Kuhn. Large language model guided self- debugging code generation, 2025

    2025

  16. [16]

    CodeBERT: A Pre-Trained Model for Programming and Natural Languages

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, et al. Codebert: A pre-trained model for programming and natural languages.arXiv preprint arXiv:2002.08155, 2020

    work page internal anchor Pith review arXiv 2002

  17. [17]

    CodeT5: Identifier-aware Unified Pre-trained Encoder-Decoder Models for Code Understanding and Generation

    Yue Wang, Weishi Wang, Shafiq Joty, and Steven CH Hoi. Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation.arXiv preprint arXiv:2109.00859, 2021

    work page internal anchor Pith review arXiv 2021

  18. [18]

    Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press

    John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. Swe-agent: Agent-computer interfaces enable automated software engineering, 2024

    2024

  19. [19]

    Autocoderover: Au- tonomous program improvement, 2024

    Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. Autocoderover: Au- tonomous program improvement, 2024

    2024

  20. [20]

    A survey on code generation with llm-based agents, 2025

    Yihong Dong, Xue Jiang, Jiaru Qian, Tian Wang, Kechi Zhang, Zhi Jin, and Ge Li. A survey on code generation with llm-based agents, 2025

    2025

  21. [21]

    Enhancing llm code generation: A systematic evaluation of multi-agent collaboration and runtime debugging for improved accuracy, reliability, and latency, 2025

    Nazmus Ashrafi, Salah Bouktif, and Mohammed Mediani. Enhancing llm code generation: A systematic evaluation of multi-agent collaboration and runtime debugging for improved accuracy, reliability, and latency, 2025

    2025

  22. [22]

    Ashraful Islam, Mohammed Eunus Ali, and Md Rizwan Parvez

    Md. Ashraful Islam, Mohammed Eunus Ali, and Md Rizwan Parvez. Codesim: Multi-agent code generation and problem solving through simulation-driven planning and debugging, 2025

    2025

  23. [23]

    Repairagent: An autonomous, llm-based agent for program repair, 2024

    Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. Repairagent: An autonomous, llm-based agent for program repair, 2024

    2024

  24. [24]

    Measuring mathematical problem solving with the math dataset, 2021

    Dan Hendrycks, Collin Burns, Saurav Kadavath, Akul Arora, Steven Basart, Eric Tang, Dawn Song, and Jacob Steinhardt. Measuring mathematical problem solving with the math dataset, 2021

    2021

  25. [25]

    Codecontests+: High-quality test case generation for competitive programming, 2025

    Zihan Wang, Siyao Liu, Yang Sun, Hongyan Li, and Kai Shen. Codecontests+: High-quality test case generation for competitive programming, 2025

    2025

  26. [26]

    Measuring coding challenge competence with apps, 2021

    Dan Hendrycks, Steven Basart, Saurav Kadavath, Mantas Mazeika, Akul Arora, Ethan Guo, Collin Burns, Samir Puranik, Horace He, Dawn Song, and Jacob Steinhardt. Measuring coding challenge competence with apps, 2021

    2021

  27. [27]

    Gaunt, Marc Brockschmidt, Sebastian Nowozin, and Daniel Tarlow

    Matej Balog, Alexander L. Gaunt, Marc Brockschmidt, Sebastian Nowozin, and Daniel Tarlow. Deepcoder: Learning to write programs. InInternational Conference on Learning Representa- tions, 2017. 11

    2017

  28. [28]

    Alexander Novikov, Ngân V˜u, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov, Borislav Kozlovskii, Francisco J. R. Ruiz, Abbas Mehrabian, M. Pawan Kumar, Abigail See, Swarat Chaudhuri, George Holland, Alex Davies, Sebastian Nowozin, Pushmeet Kohli, and Matej Balog. Alphaevolve: A coding agent for scientific and algor...

    2025

  29. [29]

    Camel: Communicative agents for "mind" exploration of large language model society, 2023

    Guohao Li, Hasan Abed Al Kader Hammoud, Hani Itani, Dmitrii Khizbullin, and Bernard Ghanem. Camel: Communicative agents for "mind" exploration of large language model society, 2023

    2023

  30. [30]

    MetaGPT: Meta programming for a multi-agent collaborative framework

    Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. MetaGPT: Meta programming for a multi-agent collaborative framework. InThe Twelfth International Conference on Learning Representations, 2024

    2024

  31. [31]

    Autogen: Enabling next-gen LLM applications via multi-agent conversations

    Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W White, Doug Burger, and Chi Wang. Autogen: Enabling next-gen LLM applications via multi-agent conversations. InFirst Conference on Language Modeling, 2024

    2024

  32. [32]

    Agentverse: Facilitating multi-agent collaboration and exploring emergent behaviors

    Weize Chen, Yusheng Su, Jingwei Zuo, Cheng Yang, Chenfei Yuan, Chi-Min Chan, Heyang Yu, Yaxi Lu, Yi-Hsin Hung, Chen Qian, Yujia Qin, Xin Cong, Ruobing Xie, Zhiyuan Liu, Maosong Sun, and Jie Zhou. Agentverse: Facilitating multi-agent collaboration and exploring emergent behaviors. InThe Twelfth International Conference on Learning Representations, 2024

    2024

  33. [33]

    Mas-gpt: Training llms to build llm-based multi-agent systems, 2025

    Rui Ye, Shuo Tang, Rui Ge, Yaxin Du, Zhenfei Yin, Siheng Chen, and Jing Shao. Mas-gpt: Training llms to build llm-based multi-agent systems, 2025

    2025

  34. [34]

    Autoagent: A fully-automated and zero-code framework for llm agents, 2025

    Jiabin Tang, Tianyu Fan, and Chao Huang. Autoagent: A fully-automated and zero-code framework for llm agents, 2025

    2025

  35. [35]

    Ai-for-science low-code platform with bayesian adversarial multi-agent framework, 2026

    Zihang Zeng, Jiaquan Zhang, Pengze Li, Yuan Qi, and Xi Chen. Ai-for-science low-code platform with bayesian adversarial multi-agent framework, 2026

    2026

  36. [36]

    Ashraful Islam, Mohammed Eunus Ali, and Md Rizwan Parvez

    Md. Ashraful Islam, Mohammed Eunus Ali, and Md Rizwan Parvez. MapCoder: Multi-agent code generation for competitive problem solving. In Lun-Wei Ku, Andre Martins, and Vivek Srikumar, editors,Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 4912–4944, Bangkok, Thailand, August 2024. Asso...

    2024

  37. [37]

    ChatDev: Communicative agents for software development

    Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, Juyuan Xu, Dahai Li, Zhiyuan Liu, and Maosong Sun. ChatDev: Communicative agents for software development. In Lun-Wei Ku, Andre Martins, and Vivek Srikumar, editors,Proceedings of the 62nd Annual Meeting of the Association for Computational Li...

    2024

  38. [38]

    Nguyen, and Nghi D

    Minh Huynh Nguyen, Thang Phan Chau, Phong X. Nguyen, and Nghi D. Q. Bui. Agilecoder: Dynamic collaborative agents for software development based on agile methodology, 2024

    2024

  39. [39]

    Zhang, Michael Luck, Qingwen Bu, Yuhao Qing, and Heming Cui

    Dong Huang, Jie M. Zhang, Michael Luck, Qingwen Bu, Yuhao Qing, and Heming Cui. Agentcoder: Multi-agent-based code generation with iterative testing and optimisation, 2024

    2024

  40. [40]

    C-pack: Packaged resources to advance general chinese embedding, 2023

    Shitao Xiao, Zheng Liu, Peitian Zhang, and Niklas Muennighoff. C-pack: Packaged resources to advance general chinese embedding, 2023

    2023

  41. [41]

    Oi wiki.https://github.com/OI-wiki/OI-wiki, 2016

    OI Wiki Team. Oi wiki.https://github.com/OI-wiki/OI-wiki, 2016

    2016

  42. [42]

    Introducing gpt-5.2, 2025

    OpenAI. Introducing gpt-5.2, 2025. 12 A Prompt of Our Agents Prompt for Agent1 <system> You are an Algorithm Selection assistant. Output strictly machine−parsable Options and Rationales. <user> You are an Algorithm Selection assistant for competitive programming problems. Scene / Task: Given the following problem statement delimited by triple backticks, a...

    2025

  43. [43]

    Output only in English

  44. [44]

    For each Option, list an ordered array of tags (simple short tag strings)

    Propose at least one Option; you may propose multiple Options (Option1, Option2, ...). For each Option, list an ordered array of tags (simple short tag strings). Example format (must be parseable): Option1: [tag1, tag2 ...] Option2: [tag4, tag5 ...]

  45. [45]

    Each solution can have one or more algorithm labels, striving for accuracy and prioritizing quality over quantity

  46. [46]

    For each Option, also provide a short 1−3 sentence rationale immediately after the Option line

  47. [47]

    Only output Options and their Rationales

    Do not output extra commentary or notes. Only output Options and their Rationales

  48. [48]

    If multiple algorithms are viable under different constraints, present them as separate Options. Generally speaking, if a problem can be analyzed from a mathematical perspective, there should be a option that includes math−related tags; if a problem has a brute−force solution (if time constraints are not considered), there should be a option that includes...

  49. [49]

    (no domain knowledge provided)

    You SHOULD consult the list of standardized tags and short descriptions in the file: {{TAG_FILE}} Prefer tags exactly as presented in that file when applicable. Extraction rules (must follow): − Each Option must be on its own line beginning with ‘Option‘ + number + colon. − The tag list must be enclosed in square brackets. − The rationale must be on the n...

  50. [50]

    You can perform a brief simulation

    With examples, analyze the judge result carefully. You can perform a brief simulation

  51. [51]

    Identify the root cause of the failure

  52. [52]

    In this case, describe the code’s flaws in detail and briefly provide suggested modifications.)

    Decide whether the issue is: − minor and fixable locally (FIX) (You need to provide suggestions for correcting errors in the code, and provide the corrected code if necessary.) − fundamental algorithmic mistake requiring rethinking (RETHINK) (If a Wrong Answer (W A) or Time−Limited Query (TLE) occurs due to a logical error in the entire code or an incorre...

  53. [53]

    If your understanding is inconsistent with the output, please revise your understanding and take the sample as the standard, as the sample is absolutely correct

    When you encounter discrepancies between the sample output and the simulation results, reread the problem and re−understand its meaning. If your understanding is inconsistent with the output, please revise your understanding and take the sample as the standard, as the sample is absolutely correct. Guidelines: − CE: look for syntax, missing headers, wrong ...

  54. [54]

    looks like X

    **Misreading the problem statement’s semantics** − Treating "looks like X" as "is X" without verifying against the statement/examples. − Examples seen: interpreting a ‘0/1‘ string as**binary** when the task treats it as a **decimal string**; confusing "a palindromic substring exists" with "the whole string is a palindrome"

  55. [55]

    how many were deleted since last dedup, then reset

    **Wrong output target / protocol misunderstanding** − Computing a related quantity but not what the judge asks for (or missing required resets). 19 − Examples seen: outputting the number of distinct strings instead of "how many were deleted since last dedup, then reset"; printing one test case when input is "until EOF"; insufficient floating output precision

  56. [56]

    choose one from small sets with global uniqueness

    **Core modeling error (choosing the wrong abstract problem)** − Reframing the task into an unrelated classic template and building a solution on the wrong structure. − Examples seen: turning a "choose one from small sets with global uniqueness" task (bipartite matching/SDR) into topological sorting; treating a general directed graph as a DAG and running t...

  57. [57]

    for all" /

    **Ignoring or weakening quantifiers / constraint scope** − Dropping "for all" / "exists a reordering" / "global operation" nuances and solving an easier surrogate. − Examples seen: assuming local adjacency heuristics imply a global impossibility; treating global substitutions as independent per−character mappings while ignoring cycle−breaking constraints

  58. [58]

    2D conditions

    **Invalid monotonicity assumptions (two−pointers / sliding window misuse)** − Applying two pointers where feasibility is not monotone, or where the maintained predicate is not actually the target predicate. − Examples seen: sliding windows on arrays with negative values; "2D conditions" incorrectly handled with two pointers where the compared quantities d...

  59. [59]

    last value only

    **State design errors in DP / memoization** − Omitting variables that influence future transitions, causing invalid pruning/merging of states. − Examples seen: memoizing only by used−spell masks while ignoring multiplier/health/last−action state; collapsing subsequences by "last value only" and then applying non−linear aggregation (e.g., cubing), which de...

  60. [60]

    truncate to length \(n\)

    **Local greedy/inversion without a global invariant** − Greedily applying reversible−looking edits (or left−to−right construction) without enforcing global constraints like exact length, feasibility, or bijection consistency. − Typical symptoms: "truncate to length \(n\)" after expansions; always picking one ambiguous parse option first; assuming independ...

  61. [61]

    **Constraint−driven feasibility checks are missing** − Verifying only the main equation/condition but not the full constraint set (ranges, positivity, non−zero, uniqueness, etc.). − Examples seen: constructions that satisfy \(b \oplus c = a\) but produce \(0\) or out−of−range values; failing to special−case powers of two where a naive choice makes a compo...

  62. [62]

    **Complexity blindness (asymptotically or constant−factor)** − Using solutions that are theoretically or practically infeasible under constraints (or implementing an OK idea with catastrophic overhead). − Examples seen: exponential bitmask DP with \(n,m\) up to 100; per−query sorting in large query workloads; naive nested scans that devolve to \(O(n^2)\);...

  63. [63]

    read once, then process again

    **I/O parsing and stream−lifecycle mistakes** 20 − Reading the wrong shape of input (wrong number of tokens/lines), mixing ‘getline‘ with formatted reads incorrectly, or forgetting that stdin is a one−pass stream. − Examples seen: consuming an extra line for a token that is on the same line; infinite/expensive loops skipping empty lines; attempting "read ...

  64. [64]

    **Implementation fragility leading to RE/UB** − Out−of−bounds arrays, hard−coded limits that contradict constraints, recursion depth blow−ups, unsafe conversions. − Examples seen: allocating ‘dist[..., 1<<10]‘ but iterating masks up to ‘1<<m‘; fixed factorial tables too small for \(\sum a_i\); deep recursion chains causing stack overflow; ‘stoi‘ on arbitr...

  65. [65]

    **Numeric pitfalls (overflow, modulo misuse, precision)** − Using too−small integer types, performing intermediate computations in ‘int‘, applying ‘% MOD‘ where the quantity is not meant to be reduced, or printing too few decimals. − Examples seen: ‘a+b‘ overflow in ‘int‘; scanning only 0..30 bits for 64−bit problems; taking a value modulo \(MOD\) even wh...

  66. [66]

    system error

    **Incomplete submission / code not executable (CE / "system error")** − Missing braces, unfinished ‘main‘, missing I/O/output entirely, or truncated switch/case logic. − This appears repeatedly as a "didn’t finish the solution as runnable code" failure mode independent of the underlying algorithm idea. C Dataset We primarily tested on our self-built datas...

    2024

  67. [67]

    Graph & Network Algorithms Handling problems related to graph structures, shortest paths, minimum spanning trees, and flows: bfs, dfs, dijkstra, kruskal, prim, lowest_common_ancestor, max_flow, min_cost_max_flow, spfa, topological_sort, heavy_light, union_find, graph

  68. [68]

    Search & Backtracking Exhaustive or optimized search problems: backtracking, recursion, astar, parallel_binary_search, two_pointers

  69. [69]

    Dynamic Programming & State Compression (DP & Optimization) Solving optimal substructure problems: dp, bitmask_dp, monotonic_queue, meet_in_the_middle, ternary_search, patience_sorting, construc- tive, constructive_algorithms

  70. [70]

    Mathematics & Number Theory Theory Including probability, combinatorics, number theory, and randomized algorithms: math, math_number_theory, probability, randomization

  71. [71]

    String & Text Processing 21 Table 4: Tag distribution in train/test split. Tag Train Count Test Count Total Train % Test % astar 3 0 3 100.00% 0.00% backtracking 2 1 3 66.67% 33.33% bfs 45 21 66 68.18% 31.82% binary_search 91 45 136 66.91% 33.09% bitmask_dp 52 23 75 69.33% 30.67% bitwise 1 0 1 100.00% 0.00% brute_force 2 1 3 66.67% 33.33% bruteforce 2 1 3...

  72. [72]

    Data Structures Basic and advanced data structures and their applications: segment_tree, fenwick_tree, persistent_structure, priority_queue, stack, queue, hash_table

  73. [73]

    Sorting & Search Optimization Optimizing sorting and search strategies: sort, binary_search, patience_sorting, ternary_search

  74. [74]

    Geometry & Matrix Spatial computation and matrix operations: geometry, matrix, matrix_exponentiation

  75. [75]

    system error

    Greedy & Heuristics Suitable for problems with local optima: greedy, simulation, implement, brute_force, bruteforce D Experimental Resources We conducted our experiments using internal production servers. The MAS-Algorithm ran for approximately 15 hours on the dataset with 8 concurrent connections. For the training data, we used an 8-GPU cluster of H20 pr...

  76. [76]

    Read the number of vectors for L and R

  77. [77]

    Initialize variables to store the maximum and minimum values of (x+y) and (x−y) for both players

  78. [78]

    For each vector of L, calculate x+y and x−y, and update the corresponding max/min values

  79. [79]

    For each vector of R, calculate x+y and x−y, and update the corresponding max/min values

  80. [80]

    Compute the maximum Manhattan distance using the formula: max((max_x_plus_y − min_x_plus_y), (max_x_minus_y − min_x_minus_y))

Showing first 80 references.