Pith. sign in

REVIEW 5 major objections 6 minor 1 cited by

Pseudocode-Injection Magic: Enabling LLMs to Tackle Graph Computational Tasks

T0 review · 5 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read LLMs solve graph problems by writing code, not reading graphs.

desk verdict A pragmatic systems paper on LLM graph computation; the efficiency and accuracy claims are plausible but the tiny-validation-graph transfer and missing artifacts need scrutiny. read the letter →

arxiv 2501.13731 v1 pith:KXERFNBN submitted 2025-01-23 cs.CL cs.AI

Chang Gong , Wanrui Bian , Zhijie Zhang , Weiguo Zheng This is my paper · ORCID
classification cs.CLcs.AI
keywords largelanguagemodelsgraphcomputationaltaskscodegenerationpseudopromptingPythoninterpreterinferencecostreductionNP-completeproblemstrial-and-errorrepair
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper argues that large language models fail at graph computational tasks mainly because they cannot read graph structure from serialized text, not because they lack algorithmic knowledge. It proposes PIE, a framework that keeps the LLM's role to understanding the problem and generating Python code, guided by task-related pseudocode, and lets an interpreter do all graph reading and execution. On nine graph tasks, PIE reports 100% accuracy on the four polynomial-time problems and far higher accuracy and feasible rates than text-serialization baselines on NP-complete problems. Because the same generated code is reused on every test graph, PIE reduces LLM calls per task from one thousand to around four. The article claims this makes LLM-based graph reasoning more accurate and much cheaper.

What carries the argument

The mechanism that carries the argument is the pseudocode-injection prompt combined with a trial-and-error selection loop. Pseudocode extracted from the literature is standardized and inserted between the problem description and the requested function signature; it guides the LLM to an efficient algorithm, for example a greedy nearest-neighbor construction instead of exhaustive enumeration for the traveling salesman problem. The loop runs the generated code on ten graphs with fewer than ten nodes, feeds any runtime error message back to the LLM for correction, and after up to ten trials selects the best code found. This small validation set is what makes the whole approach cheap, but it is also the step that must transfer to larger graphs.

What would settle it

Run PIE with the small validation graphs drawn from one graph family (say, sparse paths) and the evaluation graphs drawn from a different family (say, dense cliques with random edge deletions); if the generated code passes validation but its large-graph accuracy collapses, the transfer assumption fails. A direct version is to record, task by task, whether the code that passes the small validation set is the same code that produces the reported large-graph numbers.

Watch

Extended reading notes

Core claim

The central claim is that graph structure comprehension is the bottleneck: when an LLM is asked to reason over a serialized graph, it misreads basic properties such as edge counts and degrees, and hallucinates during computation, while the cost of including the graph in the prompt scales with the number of edges. PIE removes the graph from the prompt entirely. It prompts the LLM to write a function for a given task, supplies a pseudocode template to steer the algorithm away from brute force, and then runs the function on the raw graph with a Python interpreter. After a trial-and-error phase on ten tiny graphs, the resulting code is reused on all evaluation graphs, so the LLM is never invoked per test case. The authors assert that this yields the strongest accuracy in the comparison while maintaining the lowest inference cost.

Load-bearing premise

The code that passes on ten tiny validation graphs is assumed to stay correct on the much larger and differently generated evaluation graphs, with no check that the two distributions match.

Editorial extensions

If this is right

  • The LLM's per-task cost becomes nearly constant: once correct code is generated, any number of graphs can be processed without further LLM calls.
  • Accuracy on the four polynomial-time tasks is exactly 100% on both small and large graphs, independent of the LLM backbone.
  • On NP-complete tasks, all PIE outputs are feasible solutions, and approximation ratios are far lower than those of text-serialization baselines.
  • The framework scales to graphs whose edge count far exceeds the LLM's context window, because the interpreter, not the prompt, holds the graph.
  • A small 8-billion-parameter model matches the accuracy of a 70-billion-parameter model inside PIE, making the approach cheaper still.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The accuracy ceiling of PIE is set by the pseudocode's algorithm, not by the LLM's reasoning; for TSP, the greedy nearest-neighbor heuristic defines what correctness can mean, so the reported accuracy measures adherence to that heuristic.
  • The same 'write code against structured data, let a runtime read the data' pattern may transfer to other structured domains where serialization destroys information, such as trees, grids, or relational tables.
  • A testable refinement is to make the validation set adaptive or distributionally matched to deployment data; the paper gives no generator for the small validation graphs, leaving open how much the results depend on that match.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 6 minor

Summary. The paper introduces PIE, a framework for using LLMs to solve graph computational tasks by having the LLM generate executable Python code from a task description plus an injected pseudocode prompt, then validating the code on a small set of graphs via trial-and-error and finally executing the best code with an interpreter. The authors claim that this approach substantially improves accuracy over five text-prompt baselines across nine graph tasks (four polynomial-time and five NP-complete) with two Llama3 backbones and DeepSeek-V3, while also reducing LLM inference cost because the LLM is called only during code generation and the generated code is reused for all test instances.

Significance. If the central claims hold, PIE would be a useful practical contribution: it cleanly separates the subtasks that LLMs do well (understanding problem descriptions and writing code) from those they do poorly (reading serialized graph structures and executing precise computations), and the pseudocode-injection idea is a plausible way to steer LLMs away from brute-force algorithms. The paper provides a fairly broad evaluation with nine tasks, multiple LLM backbones, and several baselines, and the appendix includes many prompt and code examples, which helps the reader understand the mechanism. However, the manuscript currently lacks code/data release, repeated-run statistical analysis, a precise specification of the small validation set used for code selection, and a standard treatment of approximation guarantees; these omissions directly affect the credibility of the headline accuracy and efficiency claims.

major comments (5)
  1. [§3.4, Algorithm 1] The code-selection procedure is not reproducible as described. dsmall is defined only as '10 small-scale graphs (|N| < 10)' and the test function f is never specified, so a reader cannot reconstruct the selection process. More importantly, the paper offers no evidence that passing tests on <10-node graphs transfers to accurate performance on the 20–100 node evaluation graphs. Table 2 shows that PIE's large-graph accuracy drops to 28.7% for MCS and 27.4% for TSP from 85.0% and 80.2% on small graphs, which is exactly the pattern one would expect if a greedy heuristic selected on tiny instances does not maintain its quality on larger instances. Because the central claim of 'significantly higher accuracy' depends on this transfer step, the authors should specify the dsmall generator, define f, and analyze the small-to-large graph transfer gap, especially for the NP-complete tasks.
  2. [§4.2, Figure 4, Table 3] The efficiency claim is based solely on LLM inference cost (single-call time and number of LLM calls), not on total computational cost including interpreter execution. The paper's own Table 4 shows that some generated code cannot produce a result within 50 seconds on large graphs ('—'), so the end-to-end runtime of PIE on large graphs is not necessarily lower than that of baselines. The abstract's assertion that PIE has 'the lowest computational cost' is therefore not established by the reported metrics and should be qualified to 'lowest LLM inference cost' or supported with wall-clock execution times that include the interpreter's runtime.
  3. [§4.1, Approximation Ratio] The metric called 'Approximation Ratio' is defined as (1/T) Σ_i |p_i - p*_i| / |p*_i|, which is the average relative error, not the standard approximation ratio used in the algorithms literature (for minimization problems, an approximation ratio is at least 1 and bounds the worst-case ratio). The claims based on Figure 2, including 'our method's approximation ratio is less than 1/10 of other methods,' rely on this non-standard metric and do not establish standard approximation guarantees. The authors should either use the standard definition or clearly rename the metric to 'average relative error' and avoid conclusions that require the standard notion of approximation ratio.
  4. [§4.1, Experimental Settings] All experimental results are reported from single runs without error bars, confidence intervals, or repeated-seed analysis, despite the stochastic nature of LLM generation. Since several of the reported differences, especially those on large graphs for MCS and TSP, are not overwhelmingly large (e.g., 28.7% vs. ~20% for the best baseline), statistical significance cannot be assessed. In addition, no code or data are released, making it impossible to verify the results or to reproduce the dsmall-based selection procedure. These omissions are load-bearing for the paper's central claims.
  5. [§3.3, Pseudocode Prompt] The pseudocode selection process is under-specified. The paper states that pseudocode is 'extracted from multiple research papers, standardized, and input into the LLM,' and that the model is instructed to 'select the optimal one,' but it does not state how many pseudocode candidates were considered per task, which papers they came from, or what criterion defines 'optimal.' Since the injected pseudocode directly determines whether the generated code is a brute-force search or a heuristic (see the TSP example in Figures 5 and 6), the lack of specification makes the method difficult to replicate and the role of pseudocode selection in the performance gain unclear.
minor comments (6)
  1. [Abstract] In the abstract, 'P seudocode-Injection' contains an erroneous space; it should be 'Pseudocode-Injection.'
  2. [§3.1] The phrase 'code generation and executation' contains a typo; it should be 'code generation and execution.'
  3. [Table 2] The column header 'SD' is inconsistent with the task name 'Shortest Path (SP)' used in Section 2; please use the same abbreviation throughout.
  4. [Appendix A, Table 6 vs Table 3] Table 6 reports LLM call counts of 10,1,1,1,10,1,1,10,10 for the nine tasks, which sum to 45 and average 5.0, while Table 3 reports PIE averages of 4.5 (Llama3-8b) and 4.0 (Llama3-70b); please clarify how these averages are computed or whether the per-task call counts differ across backbones.
  5. [§4.2, Feasible rate discussion] The sentence 'Clearly, our approach achieves a perfect 100% across all tasks' refers to feasible rate (Figure 3), not accuracy; the text should say '100% feasible rate' to avoid confusion with the accuracy results in Table 2.
  6. [§1, Table 1 caption and §4.1] The paper calls graphs with 20–100 nodes 'large-scale,' but the authors themselves note in the introduction that Dijkstra can handle 10^6 nodes in one second; the terminology should be tempered (e.g., 'larger' rather than 'large-scale') to avoid overstatement.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the code-selection step uses a separate small validation set, and accuracy claims are evaluated on disjoint GraphArena-derived test graphs.

full rationale

The paper's derivation chain is self-contained. The only selection step is Algorithm 1, which uses a test function f on 10 small-scale graphs dsmall with fewer than 10 nodes to repair and choose generated code; dsmall is generated independently and is not the 500 small plus 500 large GraphArena-derived test graphs on which the reported accuracy is measured. There is no fitted parameter that is then renamed as a prediction: the LLM-generated code produces outputs by interpreter execution, and the pseudocode injected into prompts is collected from external research papers rather than from the authors' own prior results. No load-bearing self-citation, uniqueness theorem, or ansatz-smuggling citation appears in Sections 3 and 4; the comparison baselines are external methods with their own public prompt formats. The closest issue is that validation on fewer-than-10-node graphs may not guarantee heuristic quality on 20 to 100 node graphs, and the paper's own MCS and TSP large-graph accuracies (26-29% and 27.4%) show this transfer can fail; however, that is a generalization risk, not a circular reduction of the reported result to its own inputs. Accordingly, no specific circular step can be exhibited, and the paper receives score 0.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The ledger shows the empirical claim rests on unverified distributional alignment between validation and test graphs, on the correctness of the evaluation harness, and on the external pseudocode being sound. No free parameters are fitted to test labels; the listed parameters are hand-chosen hyperparameters. No new entities are invented.

free parameters (3)
  • K, the maximum number of retry attempts per task = 10
    Set in Section 3.4 to cap LLM calls; it directly shapes the final code quality and the average call counts in Table 3.
  • dsmall, the number and size of validation graphs = 10 graphs with fewer than 10 nodes
    Chosen in Section 3.4; the code is accepted or rejected based on this tiny validation set.
  • Degree-difference threshold in the MCS pseudocode = |degree(k1) - degree(k2)| <= 2
    Hard-coded in Appendix C.3; it controls which node pairs are added during BFS extension and affects MCS accuracy.
assumptions (4)
  • domain assumption The ten small validation graphs dsmall are drawn from the same distribution as the test graphs and are disjoint from them.
    Section 3.4 uses dsmall to select code; Section 4.1 defines test graphs following GraphArena, but the paper never states that dsmall and the test set come from the same generator or are disjoint.
  • domain assumption The interpreter and test function f compute correct ground-truth answers and identify feasible solutions correctly.
    Accuracy and Feasible Rate measurements in Section 4.1 assume f has access to exact ground truth, including for NP-complete problems like MCS and TSP.
  • domain assumption The pseudocode extracted from papers is correct, and the LLM's selection among pseudocode variants does not use test-set performance.
    Section 3.3 says the model selects the optimal pseudocode based on time and space complexity and coding difficulty, but the selection process is not described in enough detail to rule out benchmark-specific tuning.
  • domain assumption GraphArena-derived graph generation is representative of graph computational tasks at the tested sizes.
    All conclusions in Section 4.2 are based on 500 small and 500 large graphs per task following GraphArena; the maximum graph size is 100 nodes.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Pseudocode-Injection Magic: Enabling LLMs to Tackle Graph Computational Tasks." pith.science (2026). https://pith.science/paper/KXERFNBN

@misc{pith2026250113731,
  author       = {Pith},
  title        = {Pith review of: Pseudocode-Injection Magic: Enabling LLMs to Tackle Graph Computational Tasks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KXERFNBN}},
  note         = {Machine review of arXiv:2501.13731}
}
read the original abstract

Graph computational tasks are inherently challenging and often demand the development of advanced algorithms for effective solutions. With the emergence of large language models (LLMs), researchers have begun investigating their potential to address these tasks. However, existing approaches are constrained by LLMs' limited capability to comprehend complex graph structures and their high inference costs, rendering them impractical for handling large-scale graphs. Inspired by human approaches to graph problems, we introduce a novel framework, PIE (Pseudocode-Injection-Enhanced LLM Reasoning for Graph Computational Tasks), which consists of three key steps: problem understanding, prompt design, and code generation. In this framework, LLMs are tasked with understanding the problem and extracting relevant information to generate correct code. The responsibility for analyzing the graph structure and executing the code is delegated to the interpreter. We inject task-related pseudocodes into the prompts to further assist the LLMs in generating efficient code. We also employ cost-effective trial-and-error techniques to ensure that the LLM-generated code executes correctly. Unlike other methods that require invoking LLMs for each individual test case, PIE only calls the LLM during the code generation phase, allowing the generated code to be reused and significantly reducing inference costs. Extensive experiments demonstrate that PIE outperforms existing baselines in terms of both accuracy and computational efficiency.

Figures

Figures reproduced from arXiv: 2501.13731 by the authors.

Figure 1
Figure 1. Nine graph tasks and the overview of our framework. In “Problem Understanding” phase, our approach allocates the understanding [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Approximation ratio comparison of various methods on different NP-complete tasks. Lower is better. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Feasible rate comparison of various methods on different NP-complete tasks. Higher is better. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Time cost comparison for a single call to LLMs, averaging small and large graphs. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Code generated by LLMs without pseudocode. [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 7
Figure 7. Figure 7: Feasible rate comparison of various methods on different NP-complete tasks with LLM backbone DeepSeek-V3. Higher is better. [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: Approximation ratio comparison of various methods on different NP-complete tasks with LLM backbone DeepSeek-V3. Lower is [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Time cost comparison for a single call to DeepSeek-V3. [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Teaching LLM to Reason: Reinforcement Learning from Algorithmic Problems without Code

    cs.CL 2025-07 conditional novelty 6.0 of 10

    TeaR uses GRPO reinforcement learning on test-case output prediction for algorithmic problems, with no code shown, and reports broad reasoning gains across 17 benchmarks.

Reference graph

Works this paper leans on

26 extracted references · 9 canonical work pages · cited by 1 Pith paper

  1. [1]

    Gpt-4 technical report

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, and Shyamal Anadkat et al. Gpt-4 technical report. ArXiv , abs/2303.08774, 2024

    arXiv 2024

  2. [2]

    Accurate medium-range global weather forecasting with 3d neural networks

    Kaifeng Bi, Lingxi Xie, Hengheng Zhang, Xin Chen, Xiaotao Gu, and Qi Tian. Accurate medium-range global weather forecasting with 3d neural networks. Nature , 619:1--6, 07 2023

    work page 2023

  3. [3]

    Graphwiz: An instruction-following language model for graph computational problems

    Nuo Chen, Yuhan Li, Jianheng Tang, and Jia Li. Graphwiz: An instruction-following language model for graph computational problems. In Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining , page 353–364, New York, NY, USA, 2024. Association for Computing Machinery

    work page 2024

  4. [4]

    A note on two problems in connexion with graphs

    Edsger W Dijkstra. A note on two problems in connexion with graphs. Numerische mathematik , 1(1):269--271, 1959

    work page 1959

  5. [5]

    Talk like a graph: Encoding graphs for large language models

    Bahare Fatemi, Jonathan Halcrow, and Bryan Perozzi. Talk like a graph: Encoding graphs for large language models. In International Conference on Learning Representations (ICLR) , 2024

    work page 2024

  6. [6]

    The llama 3 herd of models

    Aaron Grattafiori, Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, and Alex Vaughan et al. The llama 3 herd of models. ArXiv , abs/2407.21783, 2024

    arXiv 2024

  7. [7]

    Qwen2.5-coder technical report

    Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, and Keming Lu et al. Qwen2.5-coder technical report. ArXiv , abs/2409.12186, 2024

    arXiv 2024

  8. [8]

    Graphteam: Facilitating large language model-based graph analysis via multi-agent collaboration

    Xin Li, Qizhi Chu, Yubin Chen, Yang Liu, Yaoqi Liu, Zekai Yu, Weize Chen, Chen Qian, Chuan Shi, and Cheng Yang. Graphteam: Facilitating large language model-based graph analysis via multi-agent collaboration. ArXiv , abs/2410.18032, 2024

    arXiv

Show all 26 references
  1. [9]

    Deepseek-v2: A strong, economical, and efficient mixture-of-experts language model

    Aixin Liu, Bei Feng, Bin Wang, Bingxuan Wang, Bo Liu, Chenggang Zhao, Chengqi Dengr, Chong Ruan, Damai Dai, and Daya Guo et al. Deepseek-v2: A strong, economical, and efficient mixture-of-experts language model. ArXiv , abs/2405.04434, 2024

    2024 arXiv

  2. [10]

    Deepseek-v3 technical report

    Aixin Liu, Bei Feng, Bing Xue, Bingxuan Wang, Bochao Wu, Chengda Lu, Chenggang Zhao, Chengqi Deng, Chenyu Zhang, and Chong Ruan et al. Deepseek-v3 technical report. ArXiv , abs/2412.19437, 2024

    2024 arXiv

  3. [11]

    Graphinstruct: Empowering large language models with graph understanding and reasoning capability

    Zihan Luo, Xiran Song, Hong Huang, Jianxun Lian, Chenhao Zhang, Jinqi Jiang, Xing Xie, and Hai Jin. Graphinstruct: Empowering large language models with graph understanding and reasoning capability. ArXiv , abs/2403.04483, 2024

    2024

  4. [12]

    Direct preference optimization: Your language model is secretly a reward model

    Rafael Rafailov, Archit Sharma, Eric Mitchell, Christopher D Manning, Stefano Ermon, and Chelsea Finn. Direct preference optimization: Your language model is secretly a reward model. In Thirty-seventh Conference on Neural Information Processing Systems , 2023

    2023

  5. [13]

    Kumar, Emilien Dupont, Francisco Ruiz, Jordan Ellenberg, Pengming Wang, Omar Fawzi, Pushmeet Kohli, and Alhussein Fawzi

    Bernardino Romera-Paredes, Mohammadamin Barekatain, Alexander Novikov, Matej Balog, M. Kumar, Emilien Dupont, Francisco Ruiz, Jordan Ellenberg, Pengming Wang, Omar Fawzi, Pushmeet Kohli, and Alhussein Fawzi. Mathematical discoveries from program search with large language mode...

    2023

  6. [14]

    Zhihong Shao, Peiyi Wang, Qihao Zhu, Runxin Xu, Junxiao Song, Xiao Bi, Haowei Zhang, Mingchuan Zhang, Y. K. Li, Y. Wu, and Daya Guo. Deepseekmath: Pushing the limits of mathematical reasoning in open language models. ArXiv , abs/2402.03300, 2024

    2024 arXiv

  7. [15]

    Graph reasoning with large language models via pseudo-code prompting

    Konstantinos Skianis, Giannis Nikolentzos, and Michalis Vazirgiannis. Graph reasoning with large language models via pseudo-code prompting. ArXiv , abs/2409.17906, 2024

    2024 arXiv

  8. [16]

    Grapharena: Benchmarking large language models on graph computational problems

    Jianheng Tang, Qifan Zhang, Yuhan Li, and Jia Li. Grapharena: Benchmarking large language models on graph computational problems. ArXiv , abs/2407.00379, 2024

    2024 arXiv

  9. [17]

    Can language models solve graph problems in natural language? In Thirty-seventh Conference on Neural Information Processing Systems , 2023

    Heng Wang, Shangbin Feng, Tianxing He, Zhaoxuan Tan, Xiaochuang Han, and Yulia Tsvetkov. Can language models solve graph problems in natural language? In Thirty-seventh Conference on Neural Information Processing Systems , 2023

    2023

  10. [18]

    Loomba, Shichang Zhang, Yizhou Sun, and Wei Wang

    Xiaoxuan Wang, Ziniu Hu, Pan Lu, Yanqiao Zhu, Jieyu Zhang, Satyen Subramaniam, Arjun R. Loomba, Shichang Zhang, Yizhou Sun, and Wei Wang. SciBench: Evaluating College-Level Scientific Problem-Solving Abilities of Large Language Models . In Proceedings of the Forty-First Intern...

    2024

  11. [19]

    Chi, Quoc Le, and Denny Zhou

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Ed H. Chi, Quoc Le, and Denny Zhou. Chain of thought prompting elicits reasoning in large language models. CoRR , abs/2201.11903, 2022

    2022 arXiv

  12. [20]

    Qiming Wu, Zichen Chen, Will Corcoran, Misha Sra, and Ambuj K. Singh. Grapheval2000: Benchmarking and improving large language models on graph datasets. ArXiv , abs/2406.16176, 2024

    2024 arXiv

  13. [21]

    Internlm-math: Open math large language models toward verifiable reasoning

    Huaiyuan Ying, Shuo Zhang, Linyang Li, Zhejian Zhou, Yunfan Shao, Zhaoye Fei, Yichuan Ma, Jiawei Hong, Kuikun Liu, and Ziyi Wang et al. Internlm-math: Open math large language models toward verifiable reasoning. ArXiv , abs/2402.06332, 2024

    2024 arXiv

  14. [22]

    Gcoder: Improving large language model for generalized graph problem solving

    Qifan Zhang, Xiaobin Hong, Jianheng Tang, Nuo Chen, Yuhan Li, Wenzhong Li, Jing Tang, and Jia Li. Gcoder: Improving large language model for generalized graph problem solving. ArXiv , abs/2410.19084, 2024

    2024 arXiv

  15. [23]

    Debug like a human: A large language model debugger via verifying runtime execution step by step

    Li Zhong, Zilong Wang, and Jingbo Shang. Debug like a human: A large language model debugger via verifying runtime execution step by step. In Annual Meeting of the Association for Computational Linguistics , 2024

    2024

  16. [24]

    Jiuzhang3.0: Efficiently improving mathematical reasoning by training small data synthesis models

    Kun Zhou, Beichen Zhang, Jiapeng Wang, Zhipeng Chen, Wayne Xin Zhao, Jing Sha, Zhichao Sheng, Shijin Wang, and Ji-Rong Wen. Jiuzhang3.0: Efficiently improving mathematical reasoning by training small data synthesis models. ArXiv , abs/2405.14365, 2024

    2024 arXiv

  17. [25]

    Wu, Yukun Li, Huazuo Gao, and Shirong Ma et al

    Qihao Zhu, Daya Guo, Zhihong Shao, Dejian Yang, Peiyi Wang, Runxin Xu, Y. Wu, Yukun Li, Huazuo Gao, and Shirong Ma et al. Deepseek-coder-v2: Breaking the barrier of closed-source models in code intelligence. ArXiv , abs/2406.11931, 2024

    2024 arXiv

  18. [26]

    write newline

    " write newline "" before.all 'output.state := FUNCTION fin.entry add.period write newline FUNCTION new.block output.state before.all = 'skip after.block 'output.state := if FUNCTION new.sentence output.state after.block = 'skip output.state before.all = 'skip after.sentence '...

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.