Pith. sign in

REVIEW 4 major objections 6 minor 3 cited by

Fortran2CPP: Automating Fortran-to-C++ Translation using LLMs via Multi-Turn Dialogue and Dual-Agent Integration

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

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

Pith's one-line read Fine-tuning open-weight LLMs on multi-turn dialogue data achieves up to a 3.31x CodeBLEU improvement and a 92% increase in compilation success for Fortran-to-C++ translation.

desk verdict A genuinely useful dialogue dataset for Fortran-to-C++ translation, with a real ablation showing dialogue data beats code pairs—but the execution-test metric is weaker than it looks because the oracle is the same LLM that generated the data. read the letter →

arxiv 2412.19770 v2 pith:HGKVMVVQ submitted 2024-12-27 cs.LG

Le Chen , Bin Lei , Dunzhi Zhou , Pei-Hung Lin , Chunhua Liao , Caiwen Ding , Ali Jannesari This is my paper · ORCID
classification cs.LG
keywords Fortran-to-C++translationmulti-turndialoguedatasetLLMagentQuestioner-Solverfine-tuningopen-weightLLMsCodeBLEUlow-resourcelanguagehigh-performancecomputing
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 claims that fine-tuning open-weight large language models on a multi-turn dialogue dataset improves automatic Fortran-to-C++ translation, the kind of low-resource code migration needed to modernize high-performance computing applications. The Fortran2CPP dataset records every step of an LLM-agent pipeline—initial translation, unit test generation, compilation, execution, error fixing, and final verification—mediated by a Questioner-Solver pair of LLMs, and is released publicly. When three open-weight models (DeepSeek-Coder 6.7B, CodeLlama 13B, StarCoder 15.5B) are fine-tuned on the resulting 11.7k dialogue turns, the paper reports up to a 3.31x increase in CodeBLEU and large gains in compilation and execution pass rates across two evaluation benchmarks. If true, this means translation quality can be improved by training on the process of translation rather than only on verified code pairs, a result that could extend to other low-resource programming languages.

What carries the argument

The central machinery is the Questioner-Solver module, a dual-LLM agent core in which one LLM (the Questioner) inspects the current memory and environmental tool feedback and decides what to ask, while the other (the Solver) plans and executes translation, error repair, test generation, and tool calls. This division of labor produces a multi-turn dialogue that is saved and then split into cumulative prompt-response pairs to form the Fortran2CPP training dataset. The module's iterative feedback loop—compilation, execution, unit testing, and retry—is what embeds compiler diagnostics and error-fixing steps into the training data, and the paper's ablation shows that this dialogue version outperforms fine-tuning on the same underlying code pairs alone.

What would settle it

Run a random sample of the Fortran2CPP-verified translation pairs against an independent, hand-written test suite that probes array-index boundaries, integer overflow, floating-point rounding, and I/O ordering; if a substantial fraction of pairs that passed the LLM-generated tests fail the independent suite, the functional-equivalence oracle collapses and the reported reliability gains overstate true correctness.

Watch

Extended reading notes

Core claim

The central discovery is that process-level dialogue data generated by a dual-LLM agent pipeline carries training signal that plain Fortran-C++ code pairs do not. The pipeline saves the full interaction history between a Questioner, which reads the current memory and tool feedback and asks the next question, and a Solver, which plans and executes translation, compilation, test generation, and repair actions. Those histories are split into cumulative prompt-response pairs, turning 1.2k dialogues into 11.7k training turns. Fine-tuning DeepSeek-Coder 6.7B, CodeLlama 13B, and StarCoder 15.5B on these dialogues yields consistent improvements over both their untuned versions and versions fine-tuned only on code pairs, with the largest CodeBLEU gain reaching 3.31x on the HumanEval-Fortran2Cpp benchmark and compilation success rising to 0.92 for CodeLlama. The paper interprets this as evidence that dialogue-based training embeds compiler diagnostics, error-resolution strategies, and iterative refinement behavior into the model.

Load-bearing premise

The load-bearing premise is that the unit tests generated by LLMs correctly determine whether the translated C++ code is functionally equivalent to the original Fortran program; if those tests miss important behaviors, the dataset's acceptance decisions and the reported execution-test improvements are both inflated.

Editorial extensions

If this is right

  • Fine-tuning on the dialogue dataset yields better translation quality than fine-tuning on the same underlying code pairs alone, as shown by the ablation across all metrics and both benchmarks.
  • Gains transfer from the HPC-Fortran-Cpp benchmark to the more diverse HumanEval-Fortran2Cpp benchmark, indicating the dataset teaches transferable Fortran-to-C++ patterns rather than overfitting one corpus.
  • A 13B open-weight model (CodeLlama) can match or exceed GPT-4 Turbo on CodeBLEU and compilation success while remaining open-weight and much smaller.
  • The dialogue generation pipeline scales with seed code size and iteration count, so larger datasets can be produced with the same Questioner-Solver workflow subject to compute and time constraints.
  • The released dataset and models allow independent reproduction and further fine-tuning for other code translation or migration tasks.

Reading between the lines

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

  • If the dialogue-training effect is as general as claimed, the same Questioner-Solver pipeline could be applied to other low-resource translation pairs, such as legacy COBOL to Java or MPI-to-OpenMP refactoring, wherever compilation and execution feedback loops are available.
  • The reported gains may partly reflect the dataset's emphasis on the specific compiler and runtime errors common in Fortran-to-C++ translation; whether the trained models handle genuinely novel error types is not established by the paper.
  • A stricter oracle, such as property-based differential testing between the Fortran and C++ programs, would likely change the pipeline's acceptance decisions and the measured pass rates, and the direction and size of that change remain open empirical questions.
  • A token-matched comparison of dialogue fine-tuning versus simply adding more verified code pairs would isolate whether the process signal, rather than the extra training data itself, drives the improvement.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper introduces Fortran2CPP, a pipeline that uses a dual-agent Questioner-Solver LLM module to translate Fortran code to C++, producing both a code-pair dataset and a multi-turn dialogue dataset (11.7k prompt-response pairs derived from 1.2k dialogues). The authors fine-tune DeepSeek-Coder 6.7B, CodeLlama 13B, and StarCoder 15.5B on this dialogue data and report substantial improvements over base models and over models fine-tuned on code pairs only, on two benchmarks: HPC-Fortran-Cpp (296 pairs) and a newly created HumanEval-Fortran2Cpp (126 pairs). Metrics include CodeBLEU, compilation success rate, execution-test pass ratio, and a small manual investigation. The core claim is that process-level dialogue data improves syntactic and functional translation quality more than static code-pair fine-tuning.

Significance. If the reported execution-test gains are valid, this is a well-timed contribution to low-resource code translation: it provides an open dataset, open model artifacts, and a concrete demonstration that dialogue-style agent trajectories can be exploited for fine-tuning. The ablation against code-pair fine-tuning is a valuable and relatively clean comparison, and the consistent trends across three model families strengthen the qualitative finding that dialogue data helps. However, the significance is tempered by the fact that the functional-reliability claims rest on LLM-generated unit tests used both as the dataset filter and as the evaluation oracle; independent validation is needed before the execution-test component of the claims can be accepted.

major comments (4)
  1. [§3.3.5 and §4.1] The execution-test metric is not independent of the training-data filter. In §3.3.5, the final verification asks an LLM to answer 'Yes' or 'No' on unit-test outputs before a pair is kept, and in §4.1 the Execution Test runs translated code against unit tests generated by GPT-4. Because the same class of oracle is used to filter the training data and to measure success, the reported execution-test improvements (e.g., CodeLlama 13B rising from 0.0 to 0.92 on HumanEval-Fortran2Cpp in Table 4) may partly reflect the model learning to satisfy the test-generation style rather than true functional equivalence. The Limitations section acknowledges this, but no independent validation is supplied; please add a human-audited test suite (at least on a stratified sample) or an alternative differential-testing oracle to support the functional-reliability component of the central claim.
  2. [§3.3 and §3.4] The paper does not state which LLM (or which version) plays the roles of Questioner and Solver in the Fortran2CPP generation pipeline. This matters for interpreting the results: if GPT-4 powers the pipeline, the fine-tuning results are essentially distillation from GPT-4 and should be framed and analyzed as such; if an open-weight model is used, the reproducibility and cost claims change. Please specify the backbone model, its version, and the prompting protocol, and report the dialogue-level success rate (the 29.6% figure is described as a data 'conversation rate,' which appears to be a conversion rate for code pairs).
  3. [§4.1 (HumanEval-Fortran2Cpp construction)] The HumanEval-Fortran2Cpp benchmark was created by a GPT-4-based pipeline with iterative compilation, execution, and refinement, but the correctness of the resulting Fortran reference implementations is not independently verified. Since this benchmark is used to claim functional improvements (e.g., execution ratios up to 0.92), an incorrect reference implementation could inflate or deflate measured performance. Please provide a human validation of at least a sample of the 126 Fortran references or release the verification artifacts so that correctness can be checked.
  4. [§4.2, Tables 3 and 4] No variance or repeated-run information is reported for fine-tuning or evaluation. The evaluation sets are small (296 and 126), and the differences between dialogue and code-pair fine-tuning, while consistent in direction, are not quantified with error bars or significance tests. Please report results across at least three fine-tuning seeds and, if possible, multiple evaluation samples, so that the claimed advantage of dialogue over code-pair data is not an artifact of a single run.
minor comments (6)
  1. [Abstract and §1] There is a duplicated word in the Introduction: 'achieving achieving' should be 'achieving'.
  2. [§3.4] The phrase 'with a successful data conversation rate at 29.6%' should read 'conversion rate'; the current wording is confusing.
  3. [Figure 1 and throughout] The figure contains the typo 'Fotran' for 'Fortran', and the model name is written inconsistently as 'Codellama' in some places and 'CodeLlama' in others; please standardize.
  4. [Reference list] The CodeParrot reference contains the placeholder 'Accessed: [Insert date here]'; the access date should be completed.
  5. [Appendix A.3] The dialogue-splitting example uses a trivial 'Hi/Hello' exchange and does not illustrate a Fortran translation dialogue; consider replacing it with a real excerpt from the dataset.
  6. [§4.1] The description of the Execution Test metric is underspecified: it is not clear whether the unit tests are generated from the Fortran or the C++ side, how many tests are used per pair, and how 'proportion of matching outputs' is computed when multiple tests exist; please clarify.

Circularity Check

0 steps flagged · score 2.0 of 10

No construction-level circularity found; the LLM-generated unit-test oracle is an acknowledged validity limitation, not a circular reduction of the reported gains.

full rationale

The paper's central claim is that fine-tuning open-weight LLMs on the Fortran2CPP multi-turn dialogue dataset improves Fortran-to-C++ translation. Tracing the derivation chain, the dataset generation pipeline uses LLM-generated unit tests and an LLM Yes/No final verification (Sections 3.3.3 and 3.3.5), and the Execution Test evaluation metric uses unit tests generated by GPT-4 (Section 4.1). This shared reliance on an LLM oracle is a genuine threat to the validity of the functional-reliability component, and the paper itself acknowledges it in the Limitations section: 'adopting a stricter validation process for this step would be beneficial.' However, this is not circularity in the sense of the derivation reducing to its inputs by construction. The fine-tuned models are not fitted against the evaluation tests; CodeBLEU and compilation success are computed with standard, external tools; and the paper also reports manual expert scores on randomly selected samples, which are independent of the LLM oracle. The self-citation to Lei et al. (2023) for the HPC-Fortran-Cpp benchmark involves overlapping authors, but it is used as an evaluation set, not as a load-bearing proof or uniqueness theorem, and results are replicated on the newly built HumanEval-Fortran2Cpp benchmark. No equation or fitted parameter is renamed as a prediction. The concerns raised by the reader's take are best classified as benchmark-validity and data-quality limitations, not as circular reasoning.

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

The central empirical claim rests on several unverified or weakly-verified premises. The most important is the correctness oracle: LLM-generated unit tests are used both to filter the training dialogues and to score execution success, creating a risk that the reported gains partly reflect matching the oracle rather than true functional equivalence. The dataset is also filtered by a success rate of about 29.6 percent, which may distort the training distribution toward easy cases. Many preprocessing thresholds and fine-tuning hyperparameters are hand-chosen. No new physical entities are introduced; the Questioner-Solver module is a software design.

free parameters (4)
  • Seed Fortran file count = 80,000
    The authors selected the first 80,000 of 142,038 available Fortran files from CodeParrot as seed input; this choice affects dataset size but is not fitted to outcomes.
  • Token limit for preprocessing = 600
    Fortran files with more than 600 tokens are filtered out to fit the LLM context window; this threshold is chosen by hand and affects which code is translated.
  • Dialogue subset size = 1.2K dialogues
    From the generated dialogues, only 1.2K were selected for splitting into 11.7K prompt-response pairs due to resource limits; this selection may bias toward easier or earlier dialogues.
  • Fine-tuning hyperparameters = lr 9.65e-6, weight decay 0.1, 3 epochs, seq len 1024
    These hyperparameters are chosen by hand and directly affect the magnitude of the reported improvements.
assumptions (4)
  • domain assumption Seed Fortran code from CodeParrot is representative of real legacy Fortran and is free of external dependencies after preprocessing.
    The preprocessing skips files with undefined external references, but the paper does not quantify how this filtering affects the distribution of the resulting dataset.
  • domain assumption LLM-generated unit tests correctly capture functional equivalence between Fortran and C++ programs.
    This is used both to verify training pairs and to score execution tests; the paper's Limitations section concedes a stricter validation process would be beneficial.
  • ad hoc to paper The GPT-4-based pipeline used to create HumanEval-Fortran2Cpp produced correct Fortran implementations of the HumanEval C++ problems.
    The evaluation benchmark's Fortran side is generated and validated by GPT-4, not by human experts, so errors could propagate into the benchmark.
  • domain assumption Compiler and runtime feedback (gfortran, g++, shell) is a reliable signal for syntactic and basic run correctness.
    The pipeline relies on compilation and execution success as a proxy for correctness, which misses logical errors that compile and run but produce wrong results.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Fortran2CPP: Automating Fortran-to-C++ Translation using LLMs via Multi-Turn Dialogue and Dual-Agent Integration." pith.science (2026). https://pith.science/paper/HGKVMVVQ

@misc{pith2026241219770,
  author       = {Pith},
  title        = {Pith review of: Fortran2CPP: Automating Fortran-to-C++ Translation using LLMs via Multi-Turn Dialogue and Dual-Agent Integration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HGKVMVVQ}},
  note         = {Machine review of arXiv:2412.19770}
}
read the original abstract

Translating legacy Fortran code into C++ is a crucial step in modernizing high-performance computing (HPC) applications. However, the scarcity of high-quality, parallel Fortran-to-C++ datasets and the limited domain-specific expertise in large language models (LLMs) present significant challenges for automated translation. In this paper, we introduce Fortran2CPP, a multi-turn dialogue dataset generated by a novel LLM agent-based approach that integrates a dual-LLM Questioner-Solver module to enhance translation accuracy. Our dataset comprises 11.7k dialogues capturing iterative feedback-decision workflows including code translation, compilation, execution, unit testing, and error-fixing. Using this dataset, we fine-tune several open-weight LLMs and achieve up to a 3.31x improvement in CodeBLEU scores and a 92\% increase in compilation success rate, demonstrating enhanced syntactic accuracy and functional reliability. Our findings highlight the value of dialogue-based LLM training for complex code translation tasks. The dataset and model have been open-sourced and are available on our public GitHub repository\footnote{\url{https://github.com/HPC-Fortran2CPP/Fortran2Cpp}}.

Figures

Figures reproduced from arXiv: 2412.19770 by the authors.

Figure 1
Figure 1. The questioner-solver model serves as the [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Overview of Dataset Generation Pipeline [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Comparison of C++ and Fortran source file line count distribution. [PITH_FULL_IMAGE:figures/full_fig_p012_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Comparison of C++ and Fortran keyword histograms. [PITH_FULL_IMAGE:figures/full_fig_p012_4.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 3 Pith papers

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

  1. An Agentic Workflow for Legacy HPC Modernization: Converting the Two-Electron-Integral Core of GAMESS

    cs.AI 2026-08 conditional novelty 6.0 of 10

    An agentic workflow converted the two-electron-integral core of GAMESS from Fortran 77 to Fortran 2008 with zero chemistry-relevant differences across 612 test runs.

  2. SEDCoT: Enhancing LLM-Based COBOL Code Translation via Symbolic Execution and Delta Debugging

    cs.SE 2026-07 conditional novelty 6.0 of 10

    SEDCoT combines LLM translation, symbolic-execution test generation, and delta-debugging repair to raise COBOL-to-C correctness by ≥12% over SOTA LLM baselines while preserving human-readable output.

  3. Kaizen: Metamorphic Fuzzing and Differential Testing for LLM-Translated HPC Applications

    cs.SE 2026-07 accept novelty 6.0 of 10

    Compilation success and static developer tests are unreliable proxies for semantic correctness of LLM-translated HPC code; metamorphic fuzzing plus differential testing is required to expose input-dependent errors.

Reference graph

Works this paper leans on

40 extracted references · 18 canonical work pages · cited by 3 Pith papers

  1. [1]

    online" 'onlinestring :=

    ENTRY address archivePrefix author booktitle chapter edition editor eid eprint eprinttype howpublished institution journal key month note number organization pages publisher school series title type volume year doi pubmed url lastchecked label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block STRING...

  2. [2]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize " " * FUNCT...

  3. [3]

    Wasi Uddin Ahmad, Saikat Chakraborty, Baishakhi Ray, and Kai-Wei Chang. 2021. Unified pre-training for program understanding and generation. arXiv preprint arXiv:2103.06333

    arXiv 2021

  4. [4]

    Miltiadis Allamanis, Earl T Barr, Premkumar Devanbu, and Charles Sutton. 2018. A survey of machine learning for big code and naturalness. ACM Computing Surveys (CSUR), 51(4):1--37

    2018

  5. [5]

    Le Chen, Arijit Bhattacharjee, Nesreen Ahmed, Niranjan Hasabnis, Gal Oren, Vy Vo, and Ali Jannesari. 2024 a . Ompgpt: A generative pre-trained transformer model for openmp. In European Conference on Parallel Processing, pages 121--134. Springer

    work page 2024

  6. [6]

    Le Chen, Xianzhong Ding, Murali Emani, Tristan Vanderbruggen, Pei-Hung Lin, and Chunhua Liao. 2023 a . Data race detection using large language models. In Proceedings of the SC'23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis, pages 215--223

    work page 2023

  7. [7]

    Le Chen, Pei-Hung Lin, Tristan Vanderbruggen, Chunhua Liao, Murali Emani, and Bronis de Supinski. 2023 b . Lm4hpc: Towards effective language model application in high-performance computing. In International Workshop on OpenMP, pages 18--33. Springer

    work page 2023

  8. [8]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374

    arXiv 2021

Show all 40 references
  1. [9]

    Yinghao Chen, Zehao Hu, Chen Zhi, Junxiao Han, Shuiguang Deng, and Jianwei Yin. 2024 b . Chatunitest: A framework for llm-based test generation. In Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering, pages 572--576

    2024

  2. [10]

    CodeParrot . 2024. Codeparrot/github-code dataset. https://huggingface.co/datasets/codeparrot/github-code. Accessed: [Insert date here]

    2024

  3. [11]

    Pawe Czarnul, Jerzy Proficz, and Krzysztof Drypczewski. 2020. Survey of methodologies, approaches, and challenges in parallel programming using high-performance computing systems. Scientific Programming, 2020:1--19

    2020

  4. [12]

    Xianzhong Ding, Le Chen, Murali Emani, Chunhua Liao, Pei-Hung Lin, Tristan Vanderbruggen, Zhen Xie, Alberto Cerpa, and Wan Du. 2023. Hpc-gpt: Integrating large language model for high-performance computing. In Proceedings of the SC'23 Workshops of The International Conference ...

    2023

  5. [13]

    Mark G Gray, Randy M Roberts, and Tom M Evans. 1999. Shadow-object interface between fortran 95 and c++. Computing in Science & Engineering, 1(2):63--70

    1999

  6. [14]

    Ralf W Grosse-Kunstleve, Thomas C Terwilliger, Nicholas K Sauter, and Paul D Adams. 2012. Automatic fortran to c++ conversion with fable. Source code for biology and medicine, 7(1):1--11

    2012

  7. [15]

    Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Yu Wu, YK Li, et al. 2024 a . Deepseek-coder: When the large language model meets programming--the rise of code intelligence. arXiv preprint arXiv:2401.14196

    2024 arXiv

  8. [16]

    Taicheng Guo, Xiuying Chen, Yaqi Wang, Ruidi Chang, Shichao Pei, Nitesh V Chawla, Olaf Wiest, and Xiangliang Zhang. 2024 b . Large language model based multi-agents: A survey of progress and challenges. arXiv preprint arXiv:2402.01680

    2024 arXiv

  9. [17]

    HuggingFace. 2024. T ransformers --- huggingface.co. https://huggingface.co/docs/transformers/en/index. [Accessed 14-09-2024]

    2024

  10. [18]

    Hamel Husain, Ho-Hsiang Wu, Tiferet Gazit, Miltiadis Allamanis, and Marc Brockschmidt. 2019. Codesearchnet challenge: Evaluating the state of semantic code search. arXiv preprint arXiv:1909.09436

    2019 arXiv

  11. [19]

    Seth R Johnson, Andrey Prokopenko, and Katherine J Evans. 2019. Automated fortran--c++ bindings for large-scale scientific applications. Computing in Science & Engineering, 22(5):84--94

    2019

  12. [20]

    Bin Lei, Caiwen Ding, Le Chen, Pei-Hung Lin, and Chunhua Liao. 2023. Creating a dataset for high-performance computing code translation using llms: A bridge between openmp fortran and c++. In 2023 IEEE High Performance Extreme Computing Conference (HPEC), pages 1--7. IEEE

    2023

  13. [21]

    Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Chenghao Mou, Marc Marone, Christopher Akiki, Jia Li, Jenny Chim, et al. 2023. Starcoder: may the source be with you! arXiv preprint arXiv:2305.06161

    2023 arXiv

  14. [22]

    Qinyu Luo, Yining Ye, Shihao Liang, Zhong Zhang, Yujia Qin, Yaxi Lu, Yesai Wu, Xin Cong, Yankai Lin, Yingli Zhang, et al. 2024. Repoagent: An llm-powered open-source framework for repository-level code documentation generation. arXiv preprint arXiv:2402.16667

    2024 arXiv

  15. [23]

    Karla Morris, Damian WI Rouson, M Nicole Lemaster, and Salvatore Filippone. 2012. Exploring capabilities within fortrilinos by solving the 3d burgers equation. Scientific Programming, 20(3):275--292

    2012

  16. [24]

    OpenAI. 2024. https://platform.openai.com/docs/models/gpt-4-turbo-and-gpt-4. [Accessed 13-09-2024]

    2024

  17. [25]

    Rangeet Pan, Ali Reza Ibrahimzada, Rahul Krishna, Divya Sankar, Lambert Pouguem Wassi, Michele Merler, Boris Sobolev, Raju Pavuluri, Saurabh Sinha, and Reyhaneh Jabbarvand. 2024. Lost in translation: A study of bugs introduced by large language models while translating code. I...

    2024

  18. [26]

    Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, J \'e r \'e my Rapin, et al. 2023. Code llama: Open foundation models for code. arXiv preprint arXiv:2308.12950

    2023 arXiv

  19. [27]

    Baptiste Roziere, Marie-Anne Lachaux, Lowik Chanussot, and Guillaume Lample. 2020. Unsupervised translation of programming languages. Advances in neural information processing systems, 33:20601--20611

    2020

  20. [28]

    Baptiste Roziere, Jie M Zhang, Francois Charton, Mark Harman, Gabriel Synnaeve, and Guillaume Lample. 2021. Leveraging automated unit tests for unsupervised code translation. arXiv preprint arXiv:2110.06773

    2021 arXiv

  21. [29]

    Max Sch \"a fer, Sarah Nadi, Aryaz Eghbali, and Frank Tip. 2023. An empirical evaluation of using large language models for automated unit test generation. IEEE Transactions on Software Engineering

    2023

  22. [30]

    Clovis Seragiotto, Hong-Linh Truong, Thomas Fahringer, Bernd Mohr, Michael Gerndt, and Tianchao Li. 2004. Standardized intermediate representation for fortran, java, c and c++ programs. APART Working Group Technical Report, Institute for Software Science, University of Vienna,...

    2004

  23. [31]

    Marc Szafraniec, Baptiste Roziere, Hugh Leather, Francois Charton, Patrick Labatut, and Gabriel Synnaeve. 2022. Code translation with compiler representations. arXiv preprint arXiv:2207.03578

    2022 arXiv

  24. [32]

    Imad Eddine Toubal, Aditya Avinash, Neil Gordon Alldrin, Jan Dlabal, Wenlei Zhou, Enming Luo, Otilia Stretcu, Hao Xiong, Chun-Ta Lu, Howard Zhou, et al. 2024. Modeling collaborator: Enabling subjective vision classification with minimal human effort via llm tool-use. In Procee...

    2024

  25. [33]

    Zhiruo Wang, Grace Cuenca, Shuyan Zhou, Frank F Xu, and Graham Neubig. 2022. Mconala: a benchmark for code generation from multiple natural languages. arXiv preprint arXiv:2203.08388

    2022 arXiv

  26. [34]

    Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Shaokun Zhang, Erkang Zhu, Beibin Li, Li Jiang, Xiaoyun Zhang, and Chi Wang. 2023. Autogen: Enabling next-gen llm applications via multi-agent conversation framework. arXiv preprint arXiv:2308.08155

    2023 arXiv

  27. [35]

    Frank F Xu, Uri Alon, Graham Neubig, and Vincent Josua Hellendoorn. 2022. A systematic evaluation of large language models of code. In Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming, pages 1--10

    2022

  28. [36]

    Zhen Yang, Fang Liu, Zhongxing Yu, Jacky Wai Keung, Jia Li, Shuo Liu, Yifan Hong, Xiaoxue Ma, Zhi Jin, and Ge Li. 2024. Exploring and unleashing the power of large language models in automated code translation. arXiv preprint arXiv:2404.14646

    2024 arXiv

  29. [37]

    Zihao Yi, Jiarui Ouyang, Yuwen Liu, Tianhao Liao, Zhe Xu, and Ying Shen. 2024. A survey on recent advances in llm-based multi-turn dialogue systems. arXiv preprint arXiv:2402.18013

    2024 arXiv

  30. [38]

    Pengcheng Yin and Graham Neubig. 2018. Tranx: A transition-based neural abstract syntax parser for semantic parsing and code generation. arXiv preprint arXiv:1810.02720

    2018 arXiv

  31. [39]

    Mingxuan Zhang, Bo Yuan, Hanzhe Li, and Kangming Xu. 2024. Llm-cloud complete: Leveraging cloud computing for efficient large language model-based code completion. Journal of Artificial Intelligence General science (JAIGS) ISSN: 3006-4023, 5(1):295--326

    2024

  32. [40]

    Qinkai Zheng, Xiao Xia, Xu Zou, Yuxiao Dong, Shan Wang, Yufei Xue, Lei Shen, Zihan Wang, Andi Wang, Yang Li, et al. 2023. Codegeex: A pre-trained model for code generation with multilingual benchmarking on humaneval-x. In Proceedings of the 29th ACM SIGKDD Conference on Knowle...

    2023

Pith tools

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