Pith. sign in

REVIEW 3 major objections 6 minor 73 references

SPDZCoder: Combining Expert Knowledge with LLMs for Generating Privacy-Computing Code

T0 review · 3 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 Rule-based refactoring lifts privacy-code translation to 85.9% pass@1.

desk verdict A useful first benchmark and a plausible rule-based translation pipeline, but the headline pass@1 is inflated by test-oracle-guided repair and no artifacts are released. read the letter →

arxiv 2501.00363 v2 pith:56NXEWVV submitted 2024-12-31 cs.CR cs.AIcs.SE

Xiaoning Dong , Peilin Xin , Jia Li , Wei Xu This is my paper · ORCID
classification cs.CRcs.AIcs.SE
keywords privacycomputingmulti-partycomputationMP-SPDZcodetranslationlargelanguagemodelsdata-obliviousnessgenerationbenchmarkin-contextlearning
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 tries to establish that ordinary Python functions can be translated into MP-SPDZ, a framework for multi-party privacy-preserving computation, by combining expert-derived transformation rules with an LLM, without retraining. The obstacle it identifies is 'semantic-expressing differences' at two levels: low-level mismatches in names and syntax, and high-level mismatches such as the data-obliviousness requirement and the absence of many Python library functions in MP-SPDZ. SPDZCoder handles high-level mismatches by refactoring Python into an intermediate canonical form, handles low-level mismatches with in-context demonstration rules during a single generation step, and then repairs errors by feeding execution messages back to the LLM. On a new 313-function benchmark, the paper reports 85.94% pass@1 and 92.01% pass@2, versus 63.58% and 76.36% for the best baseline. The point of caring is that privacy-computing code is hard to write by hand, so an automated translation path would lower the barrier to using MPC frameworks.

What carries the argument

Canonical Form Python (CFP): an intermediate Python representation in which high-level semantic-expressing differences have been eliminated, so that every construct has a direct counterpart in MP-SPDZ and all secret-dependent control flow is data-oblivious. Ten refactoring rules produce CFP by implementing missing functions from a small set of primitives (exp, ln, sqrt, and inverse sqrt), rewriting branches, loops, break/continue, and data-structure operations into oblivious basic forms, and replacing non-oblivious algorithms such as quick sort with oblivious alternatives such as radix sort. The generation rule then converts CFP to MP-SPDZ in one prompt, with pattern-matched demonstrations handling low-level name and syntax mismatches (for example, float to a fixed-point secret type, and an ordinary exponential call to a fixed-point library expression). The repair stage carries the remaining burden by treating execution error messages as feedback for up to three additional LLM passes.

What would settle it

Re-run SPDZCoder on SPDZEval with the test cases withheld from the repair stage (or with repair disabled) and compare against baselines run under the same condition; if the corrected pass@1 approaches the 63.58% baseline level, or if the w/orepair 73.16% advantage disappears, the central claim of superiority collapses. A cleaner test would use a held-out set of test cases generated after the benchmark was built, so the repair oracle cannot see them.

Watch

Extended reading notes

Core claim

The central claim is that the main obstacle to Python-to-MP-SPDZ translation is not LLM capability but the absence of explicit knowledge about how the two languages express the same semantics. SPDZCoder encodes that knowledge as ten refactoring rules for high-level differences and one generation rule with in-context demonstrations for low-level differences. It first rewrites Python into Canonical Form Python, in which every remaining statement has a direct or near-direct MP-SPDZ counterpart and all control flow is data-oblivious; then it translates that form to MP-SPDZ in a single LLM pass, applies a self-reflection check, and optionally repairs the output by feeding compilation, runtime, and functionality error messages back to the LLM up to three times. Evaluated on SPDZEval, 313 manually constructed function pairs in six pattern classes, the pipeline reaches 85.94% pass@1 and 92.01% pass@2 with the paper's default backbone, versus 63.58% and 76.36% for the best baseline; without the repair stage the pass@1 falls to 73.16%, and without refactoring to 33.23%, which the paper reads as evidence that the rule-based decomposition, not just test-case feedback, is doing the work.

Load-bearing premise

The headline correctness numbers assume it is acceptable for the repair stage to run the generated code against the benchmark's own test cases during generation and retry up to three times while still reporting the result as pass@1.

Editorial extensions

If this is right

  • A translation approach for a low-resource target language does not need large parallel corpora: expert rules and in-context learning replace fine-tuning data.
  • The refactoring stage is the main contributor: removing it drops pass@1 from 85.94% to 33.23%, a far larger loss than removing repair, which leaves 73.16%.
  • The rule-based gain transfers across LLM backbones: swapping in a weaker backbone still outperforms the best baseline under the default backbone.
  • The obliviousness-related rules are reusable if the source language changes; only the syntactic and library rules need to be re-derived.
  • SPDZEval gives the community a 313-pair benchmark with test cases for future comparisons of Python-to-MP-SPDZ translation.

Reading between the lines

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

  • Because the repair stage executes the benchmark's own test cases during generation, the 85.94% pass@1 is an optimistic estimate for settings where test cases are hidden; the 73.16% w/orepair figure is closer to a fair 'test cases unseen' estimate, and the comparison would be cleaner if baselines received the same oracle.
  • The CFP intermediate could outlive its Python origin: a natural-language-to-MP-SPDZ synthesizer that emits CFP first would inherit the same obliviousness guarantees, a step the paper lists as future work but does not claim.
  • If the expert-rules cost is amortized, the framework suggests a general recipe for any low-resource programming-language target: elicit semantic-expressing differences from domain experts, cache them as transformation rules, and leave only the residual translation to an LLM.
  • A stress test beyond the six pattern classes—for example, dynamic memory access or recursive functions, where oblivious counterparts are known to be hard or nonexistent—would reveal how much of the advantage is tied to the benchmark's chosen pattern coverage.
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

3 major / 6 minor

Summary. The paper proposes SPDZCoder, a rule-based framework for translating Python functions into MP-SPDZ (secure MPC) code. It collects expert knowledge about semantic-expressing differences between Python and MP-SPDZ, distills it into refactoring rules (for high-level differences such as data-obliviousness and missing libraries) and a generation rule with in-context demonstrations (for low-level naming and syntax differences), and applies them in a three-stage pipeline: refactor to a Canonical Form Python (CFP), generate MP-SPDZ, and repair via execution feedback. The authors introduce SPDZEval, a manually constructed benchmark of 313 Python/MP-SPDZ function pairs in six splits, and report pass@1/pass@2 of 85.94%/92.01% versus 63.58%/76.36% for the best baseline (OpenAI-o1 with API documentation). Ablations show that removing the repair stage drops pass@1 to 73.16% and removing refactoring drops it to 33.23%.

Significance. If the reported results are validated, the work is a meaningful step toward automating privacy-computing code generation: the framework is fully prompt-based, requires no fine-tuning data, and the ablation study gives a clear view of the contribution of each stage. The construction of a function-level Python-to-MP-SPDZ benchmark is a useful resource for the community, and the paper is honest in discussing the repair stage as optional and in reporting the without-repair ablation. However, the headline pass@1 metric is not a standard single-shot pass@1 because the repair stage uses the evaluation test cases as an oracle, which limits the strength of the central quantitative claim as currently written.

major comments (3)
  1. [Section 3.2, Section 4.2, Table 4, Table 6, Section 5.1] The headline comparison in Section 5.1 (SPDZCoder 85.94% vs. best baseline 63.58% pass@1) is not a fair single-attempt pass@1 comparison. The repair stage (Section 3.2) executes the generated code against the benchmark's test cases and iterates up to max_feedback=3 times (Section 4.2), so 'pass@1' actually means one pipeline run that may use the evaluation test oracle up to four attempts. The API-Doc baselines, including the best OpenAI-o1, are given no such repair loop, while Table 6 shows that repair contributes 12.78 absolute points (73.16% to 85.94%), more than half of the 22.36-point margin. The paper should either report the w/orepair ablation (73.16% vs. 63.58%) as the primary pass@1 result, run the baselines with the same repair mechanism, or explicitly rename the metric (e.g., pass@1-with-repair) and discuss the oracle access.
  2. [Section 4.4.2] The definition of pass@k states that k code samples are generated per problem and the problem is solved if any sample passes the unit tests. In the SPDZCoder pipeline, however, the repair stage can produce multiple outputs from a single initial sample, all informed by execution feedback from the same test cases used for scoring. The paper should clarify how pass@1 and pass@2 are computed from the repetition and max_feedback hyperparameters, and whether the test cases used for repair and for final evaluation are identical. If they are identical, the evaluation is not a standard held-out pass@k and the reported numbers should be labeled accordingly.
  3. [Section 4.4.1, Table 4] UniTrans and InterTrans also use test-execution feedback, but the best baseline in the headline comparison (API-Doc with OpenAI-o1) does not. Since the paper does not report API-Doc baselines augmented with the same repair prompts, the reader cannot tell how much of the 22.36-point margin comes from the repair advantage rather than from the rule-based refactoring and generation stages. The w/orepair row (73.16%) suggests the qualitative conclusion may still hold, but the quantitative central claim as written is not supported by a like-for-like comparison.
minor comments (6)
  1. [Section 2.2] 'secrete int' and 'secrete fixed float' should be 'secret int' and 'secret fixed float'.
  2. [Section 3.2, Section 4.2] 'incoporate' (Section 3.2) and 'repitition' (Section 4.2) are typos for 'incorporate' and 'repetition'.
  3. [Table 3 caption] The caption spells the benchmark name as 'SDPZEval'; it should be 'SPDZEval'.
  4. [Table 4] In the API-Doc DeepSeek-V2.5 row, the pass@2 array column shows '1.4', which appears to be a typo for a three-digit value (likely 81.4); please verify.
  5. [General] The manuscript does not indicate whether the benchmark and the implementation will be made publicly available; a repository link or an explicit statement would improve reproducibility.
  6. [Section 4.2] The generation configuration reports temperature but not top-p or seed values, although the Internal Validity paragraph mentions these hyperparameters; concrete values should be provided for reproducibility.

Circularity Check

1 steps flagged · score 5.0 of 10

The reported pass@1 is inflated by an oracle-guided repair loop that consumes the evaluation test cases before scoring, so the headline 85.94% is not a one-shot generation result; the independent w/orepair result is lower.

  1. fitted input called prediction [Section 3.2 (Repair Stage), Section 4.2 (max_feedback=3), Section 5.2 (Table 6)]
    "In the repair stage, we optionally execute the generated MP-SPDZ code with test cases if they are available, and collect any execution error messages. ... The repair process repeats until the MP-SPDZ code is correct or the number of iterations reaches the predefined maximum retries (max_feedback)."

    The test cases used to drive the repair loop are the same test cases used to compute pass@1/pass@2. Thus the 85.94% headline is not the correctness of a single independently generated sample; it is the outcome of up to max_feedback=3 oracle-guided repair attempts, where the stopping condition is 'the code is correct' on the evaluation tests. The paper's own ablation quantifies this: removing repair drops overall pass@1 from 85.94% to 73.16% (Table 6), an absolute gain of 12.78 points. Reporting this as 'pass@1' against baselines that receive no such test-case feedback presents the repaired, test-conditioned output as a one-shot prediction, so the central quantitative claim is partly constructed from the evaluation target.

full rationale

The core method is not circular in the definitional sense: the transformation rules are elicited from MPC experts and from documented Python/MP-SPDZ semantic differences, not fitted to SPDZEval outputs, and the benchmark ground truths were written manually by a student and an engineer rather than derived by the pipeline. No parameter is fitted to the benchmark and no load-bearing claim depends on a self-citation chain; the few self-references (e.g., PrivPy, UniTrans) are not used to justify the central result. The one substantial circularity concern is the evaluation protocol: the repair stage consumes the benchmark test cases as feedback and then the same test cases are used to score pass@1, so the headline 85.94% is partly manufactured by the oracle loop. The paper does include the w/orepair ablation (73.16% pass@1), and that still exceeds the best baseline 63.58%, so the qualitative claim of superiority survives independent of the repair oracle. However, the headline comparison '85.94% vs 63.58%' is not an apples-to-apples one-shot comparison, and over half of the headline margin comes from the test-guided repair gain. This is a partial, evaluation-level circularity rather than a derivation-level equivalence, so the score is moderate rather than extreme. Additional concerns such as the benchmark being self-built and small are external-validity issues rather than circularity.

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

The central empirical claim rests on hand-set hyperparameters, the correctness of the MP-SPDZ API semantics, and the correctness of the self-built benchmark ground truth. There are no invented physical entities; the Canonical Form Python (CFP) is an intermediate code representation rather than a new entity.

free parameters (3)
  • temperature = 0.7
    Set by hand for generation configuration in Section 4.2; could affect pass rates across LLMs.
  • repetition = 2
    Number of MP-SPDZ samples generated per Python function; set in Section 4.2, used to compute pass@2.
  • max_feedback = 3
    Maximum number of repair iterations in the repair stage; set in Section 4.2, directly affects the reported pass@1 since the model can retry until tests pass.
assumptions (3)
  • domain assumption MP-SPDZ API, data types, and library functions as described (e.g., sint, sfix, mpc_math, Array, Matrix) are correct and complete.
    The whole translation pipeline and evaluation assume the MP-SPDZ framework's documented semantics; errors in API usage are corrected by the self-reflection and repair prompts, but the framework's behavior is taken as ground truth (Section 2.2, Section 3.2).
  • domain assumption The manually constructed ground-truth MP-SPDZ programs and test cases in SPDZEval are correct.
    Functional correctness is measured against these test cases; if the reference implementations or test cases contain errors, all reported accuracy numbers shift (Section 4.3).
  • domain assumption Data-obliviousness is both a privacy requirement and a translation correctness criterion.
    The paper assumes non-oblivious control flow (break, continue, secret-dependent branches) must be rewritten; this is the foundation of the refactoring rules (Section 2.1, Table 1).

how reviews work

0 comments
Cite this review

Pith. "Pith review of SPDZCoder: Combining Expert Knowledge with LLMs for Generating Privacy-Computing Code." pith.science (2026). https://pith.science/paper/56NXEWVV

@misc{pith2026250100363,
  author       = {Pith},
  title        = {Pith review of: SPDZCoder: Combining Expert Knowledge with LLMs for Generating Privacy-Computing Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/56NXEWVV}},
  note         = {Machine review of arXiv:2501.00363}
}
read the original abstract

Privacy computing receives increasing attention but writing privacy computing code remains challenging for developers due to limited library functions, necessitating function implementation from scratch, and data-oblivious requirement, contradicting intuitive thinking and usual practices of programmers. Automating the generation of privacy computing code with Large Language Models can streamline development effort and lower the barrier to using privacy computing frameworks. However, existing LLMs still encounter challenges in code translation for privacy-preserving computation, such as translating Python to MP-SPDZ, due to the scarcity of MP-SPDZ data required for effective pre-training or fine-tuning. Moreover, the lack of a benchmark further complicates the evaluation of translation quality. To address the limitations, this work proposes SPDZCoder, a rule-based framework that combines LLMs with expert knowledge for generating privacy-computing code without requiring additional training data. Specifically, SPDZCoder employ a rigorous procedure for collecting high-quality expert knowledge to represent the semantic-expressing differences between Python and MP-SPDZ, and to derive transformation rules for translating Python to MP-SPDZ based on these knowledge. Then, SPDZCoder progressively converts Python code into MP-SPDZ code using transformation rules in a three stage pipeline. To evaluate SPDZCoder, we manually constructed a benchmark dataset, SPDZEval, which comprises six data splits, each representing a distinct class of challenging tasks in MP-SPDZ implementation. Extensive experiments show that SPDZCoder achieves superior performance, significantly surpassing baselines in pass@1 and pass@2. Specifically, SPDZCoder attains an overall correctness of 85.94% and 92.01% in pass@1 and pass@2, respectively, whereas the best-performing baseline achieves 63.58% and 76.36%, respectively.

Figures

Figures reproduced from arXiv: 2501.00363 by the authors.

Figure 1
Figure 1. Overall functional correctness (pass@1 and pass@2) [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Overview of SPDZCoder for automatic Python to MP-SPDZ code translation [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. QR decomposition: a difficult example for SPDZ [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Example of the repair component correcting the [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Average token consumption of SPDZCoder vs. base [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: A translation example of SPDZCoder [PITH_FULL_IMAGE:figures/full_fig_p014_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

73 extracted references · 33 canonical work pages

  1. [1]

    [n. d.]. OpenAI Platform API Reference Create Chat Completion. https:// platform.openai.com/docs/api-reference/chat/create#chat-create-temperature

    work page

  2. [2]

    [n. d.]. w3resource. https://www.w3resource.com/python-exercises/

    work page

  3. [3]

    [n. d.]. w3schools. https://www.w3schools.com/python/

    work page

  4. [4]

    Wasi Ahmad, Saikat Chakraborty, Baishakhi Ray, and Kai-Wei Chang. 2021. Uni- fied Pre-training for Program Understanding and Generation. In Proceedings of the 2021 Conference of the North American Chapter of the Association for Compu- tational Linguistics: Human Language Technologies , Kristina Toutanova, Anna Rumshisky, Luke Zettlemoyer, Dilek Hakkani-Tu...

    2021

  5. [5]

    Team Anthropic. 2023. The Claude 3 Model Family: Opus, Sonnet, Haiku. https: //www-cdn.anthropic.com

    work page 2023

  6. [6]

    Ben Athiwaratkun, Sanjay Krishna Gouda, Zijian Wang, Xiaopeng Li, Yuchen Tian, Ming Tan, Wasi Uddin Ahmad, Shiqi Wang, Qing Sun, Mingyue Shang, Su- jan Kumar Gonugondla, Hantian Ding, Varun Kumar, Nathan Fulton, Arash Farahani, Siddhartha Jain, Robert Giaquinto, Haifeng Qian, Murali Krishna Ramanathan, and Ramesh Nallapati. 2023. Multi-lingual Evaluation ...

    work page 2023

  7. [7]

    Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, and Charles Sutton. 2021. Program Synthesis with Large Language Models. https://arxiv.org/abs/2108.07732

    arXiv 2021

  8. [8]

    Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Pra- fulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, and Gretchen Krueger. 2020. Language Models are Few-Shot Learners. In Advances in Neural Information Processing Systems 33: Annual Conference on Neural Informatio...

    work page 2020

Show all 73 references
  1. [9]

    C2Rust. [n. d.]. C2Rust. https://github.com/immunant/c2rust

  2. [10]

    Federico Cassano, John Gouwar, Daniel Nguyen, Sydney Nguyen, Luna Phipps- Costin, Donald Pinckney, Ming-Ho Yee, Yangtian Zi, Carolyn Jane Anderson, Molly Q Feldman, Arjun Guha, Michael Greenberg, and Abhinav Jangda. 2023. MultiPL-E: A Scalable and Polyglot Approach to Benchmar...

    2023

  3. [11]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, and Jared Kaplan. 2021. Evaluating Large Language Mod- els Trained on Code. https://arxiv.org/abs/2107.03374

    2021 arXiv

  4. [12]

    Aakanksha Chowdhery, Sharan Narang, Jacob Devlin, Maarten Bosma, Gaurav Mishra, Adam Roberts, Paul Barham, and Hyung Won Chung. 2022. PaLM: Scaling Language Modeling with Pathways. https://arxiv.org/abs/2204.02311

    2022 arXiv

  5. [13]

    CXgo. [n. d.]. cxgo. https://github.com/gotranspile/cxgo

  6. [14]

    Hadi Amini, and Yanzhao Wu

    Badhan Chandra Das, M. Hadi Amini, and Yanzhao Wu. 2025. Security and Privacy Challenges of Large Language Models: A Survey. ACM Comput. Surv. 57, 6, Article 152 (Feb. 2025), 39 pages. doi:10.1145/3712001

    2025 doi

  7. [15]

    DeepSeek-AI. 2024. DeepSeek-V2: A Strong, Economical, and Efficient Mixture- of-Experts Language Model. arXiv:2405.04434 [cs.CL]

    2024 arXiv

  8. [16]

    DeepSeek-AI. 2024. DeepSeek-V3 Technical Report. arXiv:2412.19437 [cs.CL] https://arxiv.org/abs/2412.19437

    2024 arXiv

  9. [17]

    DeepSeek-AI, Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, and Qihao Zhu. 2025. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948 [cs.CL] https: //arxiv.org/abs/2501.12948

    2025 arXiv

  10. [19]

    Xueying Du, Mingwei Liu, Kaixin Wang, Hanlin Wang, Junwei Liu, Yixuan Chen, Jiayi Feng, Chaofeng Sha, Xin Peng, and Yiling Lou. 2024. Evaluating Large Language Models in Class-Level Code Generation. In Proceedings of the 46th IEEE/ACM International Conference on Software Engin...

    2024

  11. [20]

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, and Ming Zhou. 2020. CodeBERT: A Pre-Trained Model for Programming and Natural Languages. In Findings of the Association for Computational Linguistics: EMNLP ...

    2020 doi

  12. [21]

    Team GLM, Aohan Zeng, Bin Xu, Bowen Wang, Chenhui Zhang, Da Yin, Diego Rojas, Guanyu Feng, Hanlin Zhao, Hanyu Lai, Hao Yu, and Hongning Wang

  13. [22]

    Goldreich, S

    O. Goldreich, S. Micali, and A. Wigderson. 1987. How to play ANY mental game. In Proceedings of the Nineteenth Annual ACM Symposium on Theory of Computing (New York, New York, USA)(STOC ’87). Association for Computing Machinery, New York, NY, USA, 218–229. doi:10.1145/28395.28420

    1987

  14. [23]

    Clement, Dawn Drain, Neel Sundaresan, Jian Yin, Daxin Jiang, and Ming Zhou

    Daya Guo, Shuo Ren, Shuai Lu, Zhangyin Feng, Duyu Tang, Shujie Liu, Long Zhou, Nan Duan, Alexey Svyatkovskiy, Shengyu Fu, Michele Tufano, Shao Kun Deng, Colin B. Clement, Dawn Drain, Neel Sundaresan, Jian Yin, Daxin Jiang, and Ming Zhou. 2021. GraphCodeBERT: Pre-training Code ...

    2021

  15. [24]

    Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guant- ing Chen, Xiao Bi, Y. Wu, Y. K. Li, Fuli Luo, Yingfei Xiong, and Wenfeng Liang

  16. [25]

    Koki Hamada, Dai Ikarashi, Koji Chida, and Katsumi Takahashi. 2014. Oblivi- ous radix sort: An efficient sorting algorithm for practical secure multi-party computation. Cryptology ePrint Archive (2014)

    2014

  17. [26]

    https://arxiv.org/abs/2401.14196

    DeepSeek-Coder: When the Large Language Model Meets Programming – The Rise of Code Intelligence. https://arxiv.org/abs/2401.14196

    arXiv

  18. [27]

    Yuchao Huang, Junjie Wang, Zhe Liu, Yawen Wang, Song Wang, Chunyang Chen, Yuanzhe Hu, and Qing Wang. 2024. CrashTranslator: Automatically Reproducing Mobile Application Crashes Directly from Stack Trace. In Proceedings of the 46th IEEE/ACM International Conference on Software ...

    2024

  19. [28]

    Dan Hendrycks, Steven Basart, Saurav Kadavath, Mantas Mazeika, Akul Arora, Ethan Guo, Collin Burns, Samir Puranik, Horace He, Dawn Song, and Jacob Steinhardt. 2021. Measuring Coding Challenge Competence With APPS. NeurIPS (2021)

    2021

  20. [29]

    Java2CSharp. [n. d.]. Java 2 CSharp Translator for Eclipse. https://sourceforge. net/projects/j2cstranslator/

  21. [30]

    Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Kai Dang, et al. 2024. Qwen2.5-Coder Technical Report. arXiv (2024)

    2024

  22. [31]

    Albert Q. Jiang, Alexandre Sablayrolles, Antoine Roux, Arthur Mensch, Blanche Savary, Chris Bamford, Devendra Singh Chaplot, Diego de las Casas, Emma Bou Hanna, Florian Bressand, Gianna Lengyel, Guillaume Bour, Guillaume Lample, Lélio Renard Lavaud, Lucile Saulnier, Marie-Anne...

    2024 arXiv

  23. [32]

    Ziwei Ji, Tiezheng Yu, Yan Xu, Nayeon Lee, Etsuko Ishii, and Pascale Fung

  24. [33]

    Marcel Keller. 2020. MP-SPDZ: A Versatile Framework for Multi-Party Compu- tation. https://eprint.iacr.org/2020/521 Publication info: Published elsewhere. Minor revision. ACM CCS 2020

    2020

  25. [34]

    Sumith Kulal, Panupong Pasupat, Kartik Chandra, Mina Lee, Oded Padon, Alex Aiken, and Percy Liang. 2019. SPoC: Search-based Pseudocode to Code. In Advances in Neural Information Processing Systems 32: Annual Conference on Neural Information Processing Systems 2019, NeurIPS 201...

    2019

  26. [35]

    Aditya Kanade, Petros Maniatis, Gogul Balakrishnan, and Kensen Shi. 2020. Learning and Evaluating Contextual Embedding of Source Code. In Proceedings of the 37th International Conference on Machine Learning, ICML 2020, 13-18 July 2020, Virtual Event (Proceedings of Machine Lea...

    2020

  27. [36]

    Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Chenghao Mou, Marc Marone, Christopher Akiki, Jia Li, and Jenny Chim. 2023. StarCoder: may the source be with you! https://arxiv.org/abs/2305.06161

    2023 arXiv

  28. [37]

    Yi Li, Shaohua Wang, and Tien N. Nguyen. 2022. Fault localization to detect co- change fixing locations. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (Singapore Singapore, 2022-11-07). AC...

    2022

  29. [38]

    Yuhang Lai, Chengxi Li, Yiming Wang, Tianyi Zhang, Ruiqi Zhong, Luke Zettle- moyer, Scott Wen tau Yih, Daniel Fried, Sida Wang, and Tao Yu. 2022. DS- 1000: A Natural and Reliable Benchmark for Data Science Code Generation. https://arxiv.org/abs/2211.11501

    2022 arXiv

  30. [39]

    Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. 2023. Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation. In Thirty-seventh Conference on Neural Information Processing Systems (2023-11-02). https:/...

    2023

  31. [40]

    Ziyang Luo, Can Xu, Pu Zhao, Qingfeng Sun, Xiubo Geng, Wenxiang Hu, Chongyang Tao, Jing Ma, Qingwei Lin, and Daxin Jiang. 2023. WizardCoder: Empowering Code Large Language Models with Evol-Instruct. https://arxiv. org/abs/2306.08568

    2023 arXiv

  32. [41]

    Yi Li and Wei Xu. 2019. PrivPy: General and Scalable Privacy-Preserving Data Mining. In Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining, KDD 2019, Anchorage, AK, USA, August 4-8, 2019, Ankur Teredesai, Vipin Kumar, Ying Li, Róme...

    2019

  33. [42]

    Cogo, and Bram Adams

    Marcos Macedo, Yuan Tian, Pengyu Nie, Filipe R. Cogo, and Bram Adams. 2025. InterTrans: Leveraging Transitive Intermediate Translations to Enhance LLM- based Code Translation. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE Computer Society,...

    2025

  34. [43]

    Mir, Evaldas Latoškinas, and Georgios Gousios

    Amir M. Mir, Evaldas Latoškinas, and Georgios Gousios. 2021. ManyTypes4Py: A Benchmark Python Dataset for Machine Learning-based Type Inference. IEEE Computer Society, 585–589. doi:10.1109/MSR52588.2021.00079

    2021

  35. [45]

    Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, and Caiming Xiong. 2023. CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis. InThe Eleventh International Conference on Learning Representations, ICLR 2023, ...

    2023

  36. [46]

    OpenAI. 2024. GPT-4o. https://openai.com/index/gpt-4o-system-card/

    2024

  37. [47]

    Payman Mohassel and Peter Rindal. 2018. ABY3: A Mixed Protocol Framework for Machine Learning. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (New York, NY, USA, 2018) (CCS ’18). Association for Computing Machinery, 35–52. doi:10.1145/...

    2018

  38. [48]

    OpenAI, Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, and Red Avila. 2023. GPT-4 Technical Report. https://arxiv.org/abs/2303.08774

    2023 arXiv

  39. [49]

    Gemini Team, Rohan Anil, Sebastian Borgeaud, Yonghui Wu, Jean-Baptiste Alayrac, Jiahui Yu, Radu Soricut, Johan Schalkwyk, and Andrew M. Dai. 2023. Gemini: A Family of Highly Capable Multimodal Models. https://arxiv.org/abs/ 2312.11805

    2023 arXiv

  40. [50]

    OpenAI. 2025. OpenAI o1. https://openai.com/o1/

    2025

  41. [51]

    Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timothée Lacroix, Baptiste Rozière, Naman Goyal, Eric Hambro, Faisal Azhar, Aurelien Rodriguez, Armand Joulin, Edouard Grave, and Guil- laume Lample. 2023. LLaMA: Open and Efficient Foundation ...

    2023 arXiv

  42. [52]

    Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Almahairi, Yas- mine Babaei, Nikolay Bashlykov, Soumya Batra, and Prajjwal Bhargava. 2023. Llama 2: Open Foundation and Fine-Tuned Chat Models. https://arxiv.org/abs/ 2307.09288

    2023 arXiv

  43. [53]

    Qwen Team. 2024. QwQ: Reflect Deeply on the Boundaries of the Unknown. https://qwenlm.github.io/blog/qwq-32b-preview/

    2024

  44. [54]

    Yue Wang, Weishi Wang, Shafiq Joty, and Steven C.H. Hoi. 2021. CodeT5: Identifier-aware Unified Pre-trained Encoder-Decoder Models for Code Un- derstanding and Generation. In Proceedings of the 2021 Conference on Empiri- cal Methods in Natural Language Processing , Marie-Franc...

    2021 doi

  45. [55]

    BigScience Workshop, Teven Le Scao, Angela Fan, Christopher Akiki, Ellie Pavlick, Suzana Ilić, Daniel Hesslow, Roman Castagné, and Alexandra Sasha Luccioni. 2022. BLOOM: A 176B-Parameter Open-Access Multilingual Language Model. https://arxiv.org/abs/2211.05100

    2022 arXiv

  46. [56]

    Yue Wang, Hung Le, Akhilesh Gotmare, Nghi Bui, Junnan Li, and Steven Hoi

  47. [57]

    In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, Houda Bouamor, Juan Pino, and Kalika Bali (Eds.)

    CodeT5+: Open Code Large Language Models for Code Understanding and Generation. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, Houda Bouamor, Juan Pino, and Kalika Bali (Eds.). Association for Computational Linguistics, Singapore, 10...

    2023

  48. [58]

    Andrew C. Yao. 1982. Protocols for secure computations. In 23rd Annual Symposium on Foundations of Computer Science (sfcs 1982) (1982-11). 160–164. doi:10.1109/SFCS.1982.38 ISSN: 0272-5428

    1982 doi

  49. [59]

    Pengcheng Yin, Bowen Deng, Edgar Chen, Bogdan Vasilescu, and Graham Neu- big. 2018. Learning to Mine Aligned Code and Natural Language Pairs from Stack Overflow. In Proceedings of the 15th International Conference on Mining Software Repositories (New York, NY, USA, 2018-05-28)...

    2018

  50. [60]

    Aidan Z. H. Yang, Claire Le Goues, Ruben Martins, and Vincent J. Hellendoorn

  51. [62]

    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. Proceedings of the ACM on Software Engineering 1, FSE (July 2024),...

    2024 doi

  52. [65]

    Hao Yu, Bo Shen, Dezhi Ran, Jiaxin Zhang, Qi Zhang, Yuchi Ma, Guangtai Liang, Ying Li, Qianxiang Wang, and Tao Xie. 2024. CoderEval: A Benchmark of Pragmatic Code Generation with Generative Pre-trained Models. In Proceedings of the 46th IEEE/ACM International Conference on Sof...

    2024

  53. [66]

    Qinkai Zheng, Xiao Xia, Xu Zou, Yuxiao Dong, Shan Wang, Yufei Xue, Lei Shen, Zihan Wang, Andi Wang, Yang Li, Teng Su, Zhilin Yang, and Jie Tang

  54. [67]

    ""Root mean square propagation step

    CodeGeeX: A Pre-Trained Model for Code Generation with Multilingual Benchmarking on HumanEval-X. In Proceedings of the 29th ACM SIGKDD Con- ference on Knowledge Discovery and Data Mining (New York, NY, USA)(KDD ’23). Association for Computing Machinery, 5673–5684. doi:10.1145/...

  55. [68]

    Here are the correct examples to import Python and MP-SPDZ modules

    Rectify those incorrectly imported modules. Here are the correct examples to import Python and MP-SPDZ modules. If `mpc_math` is used, never forget to import it! ``` # import math related module import math from Compiler import mpc_math # import type related module from Compil...

  56. [69]

    Rectify non-exist MP-SPDZ Functions. - `mpc_math.exp(x)` should be `mpc_math.pow_fx(math.e, x) ` which computes `e^x` - `mpc_math.log(x)` should be `mpc_math.log_fx(x, math.e) ` which computes `ln(x)` - `mpc_math.log_fx(x, cfix(math.e)) should be `mpc_math.log_fx(x, math.e) ` ...

  57. [70]

    Delete/Remove the part of `example usage of the function ` in the code if applicable

  58. [71]

    Tenary expression `x if condition else y ` should be `condition.if_else(x,y)`

  59. [72]

    {COMPILATION_RUNTIME_ERROR}

    `mpc_math.max(y, 0) ` should be `y.get_vector().max(0)`. Strictly follow the above 5 aspects and start to review the code. If applicable, return the modified code, otherwise return the original code as your response. ```MP-SPDZ {CODE} ``` Table 11: Prompt template for Self-ref...

  60. [73]

    The critical parameters or variables must keep the same name

    The code you write must have the same functionality as the original code. The critical parameters or variables must keep the same name

  61. [74]

    For example, you should change the `list` type into `Array` type

    You should use the types and methods of the MP-SPDZ framework correctly to rewrite the code. For example, you should change the `list` type into `Array` type

  62. [75]

    All variables should be viewed as ciphertext variables, and you should turn them into secret types in MP-SPDZ and should not reveal them

  63. [76]

    Table 13: Prompt templates for API Doc Baseline

    You only need to guarantee the functionality of the code you write matches the input code, and you don 't have to align the implementation between the input and your answer. Table 13: Prompt templates for API Doc Baseline

  64. [2023]

    In Findings of the Association for Computational Linguistics: EMNLP 2023 , Houda Bouamor, Juan Pino, and Kalika Bali (Eds.)

    Towards Mitigating LLM Hallucination via Self Reflection. In Findings of the Association for Computational Linguistics: EMNLP 2023 , Houda Bouamor, Juan Pino, and Kalika Bali (Eds.). Association for Computational Linguistics, Singapore, 1827–1843. doi:10.18653/v1/2023.findings...

    2023 doi

  65. [2024]

    arXiv:2406.12793

    ChatGLM: A Family of Large Language Models from GLM-130B to GLM-4 All Tools. arXiv:2406.12793

    arXiv

Pith tools

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