Pith. sign in

REVIEW 5 major objections 5 minor 31 references

IGC: Integrating a Gated Calculator into an LLM to Solve Arithmetic Tasks Reliably and Efficiently

T0 review · 5 major / 5 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 This paper claims that a frozen 8B LLM with a 17M-parameter gated calculator module solves five-digit arithmetic at 98–99% accuracy in a single forward pass, without external tools or intermediate tokens.

desk verdict The IGC is a genuinely new mechanism for exact arithmetic inside an LLM, and the BigBench results are strong enough to merit refereeing, but the posted paper is not yet reproducible and the side-effect claim is asserted rather than shown. read the letter →

arxiv 2501.00684 v1 pith:B55W6GWM submitted 2025-01-01 cs.LG cs.CL

Florian Dietz , Dietrich Klakow This is my paper · ORCID
classification cs.LGcs.CL
keywords arithmeticreasoninglargelanguagemodelsintegratedgatedcalculatorBigBenchtokenizationparameter-efficientfinetuningmultiplicationtooluse
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

Arithmetic remains a stubborn weakness of large language models, and no prior method solved the multiplication subtask of the BigBench Arithmetic benchmark without external tools or multi-step generation. This paper proposes the Integrated Gated Calculator (IGC), a small trainable module inserted into a frozen LLM that extracts the operands and operator from the model's hidden states, computes the exact result with a non-differentiable tensor-based calculator on the GPU, and injects the result back through learned gates. On the benchmark, the modified Llama 3.1 8B model reaches 98–99% accuracy across addition, subtraction, multiplication, and division, beating models nearly two orders of magnitude larger and a same-size finetuning baseline. If the result holds, exact arithmetic can be treated as an internal subroutine of an LLM rather than something the model must generate token by token.

What carries the argument

The load-bearing mechanism is the IGC's division of labor: a learned extractor, a deterministic calculator, and a learned injector. The Input Mapping submodule is an attention mechanism that, at the anchor token, gathers the tokens carrying the numbers and operator and produces fixed-length categorical digit distributions in a left-aligned format; left alignment is chosen to match Llama 3.1's chunked left-to-right tokenization of numbers, so each digit position maps to a predictable token. The calculator is a sequence of non-differentiable tensor operations (digit-to-integer conversion, parallel addition, subtraction, multiplication, and division, and integer-to-left-aligned-digit conversion), which blocks gradients and forces the auxiliary loss for the Input Mapping. The Output Mapping submodule uses separate learned gating weights per output token, so it can leave tokens unchanged when no arithmetic is needed. This gating is what lets the module avoid destructive interference on non-arithmetic tasks.

What would settle it

Generate BigBench-style test items with the benchmark's own operand generator, run the trained IGC, and inspect the extractor's digit-wise outputs before the calculator fires; if even a small fraction (say, over 1%) of test inputs are mis-parsed into the wrong operands or operator, the claimed 98–99% accuracy cannot be sustained.

Watch

Extended reading notes

Core claim

The central claim is that an LLM's arithmetic failures can be bypassed by routing the calculation through a small, explicitly supervised calculator module rather than by making the network learn arithmetic from examples. The IGC is placed after layer 1 of a frozen Llama 3.1 8B model. At an anchor token marking the end of the user's request, the Input Mapping submodule uses attention over preceding tokens to output categorical distributions over the two operands and the operator; the most probable values are discretized and fed to a GPU-emulated calculator that performs all four operations in parallel and returns a left-aligned one-hot digit result; the Output Mapping submodule then uses learned per-token gates to add the result into subsequent hidden states. Training is split: the Input Mapping is supervised by an auxiliary cross-entropy loss with ground-truth operands, while the Output Mapping learns through the LLM's normal loss. On the BigBench Arithmetic benchmark this configuration reports 99% overall accuracy, 99% on addition, subtraction, and multiplication, and 98% on division, outperforming the best n-shot PaLM 535B result and a parameter-matched finetuning adapter baseline.

Load-bearing premise

The load-bearing premise is that the small learned extractor can reliably read the correct operands and operator out of the LLM's hidden states at the moment the request ends, even when the test inputs come from a different random-number distribution than the synthetic training data; the paper itself attributes its slightly lower division score to exactly that mismatch.

Editorial extensions

If this is right

  • A frozen 8B LLM plus a 17M-parameter module can perform exact 5-digit arithmetic in constant time, with no intermediate output tokens; this removes the main efficiency cost of chain-of-thought for arithmetic.
  • Because the comparison includes a same-size finetuning adapter baseline at 70% overall and 22% on multiplication, the reported gap attributes the gain to the calculator mechanism rather than to finetuning per se.
  • The module's gated outputs mean tasks without arithmetic are left nearly unaffected, so adding the IGC should not degrade unrelated capabilities.
  • The same three-part design (extract, non-differentiable black-box operation, re-inject with gates) can be pointed at other discrete operations, such as lookups, and the paper argues it could be trained during pretraining as a subroutine for word problems.

Reading between the lines

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

  • Editorially, the result suggests that LLM arithmetic errors are dominated by operand extraction and output formatting rather than by the absence of computational machinery; the IGC essentially converts arithmetic into a reading-comprehension task plus a lookup.
  • A testable extension is to evaluate the Input Mapping's digit-wise accuracy directly on out-of-template phrasings; if it degrades while the calculator remains perfect, extraction, not computation, is the binding constraint.
  • Another extension is to chain multiple IGC executions for multi-step arithmetic or larger operands; the paper's fixed-length design implies accuracy should stay perfect up to the trained length and then need external tools.
  • The left-aligned tokenization analysis implies tokenizer design may matter more than model scale for arithmetic; other tokenizers would need their own alignment scheme, which the paper's code is meant to automate.
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 / 5 minor

Summary. The paper introduces the Integrated Gated Calculator (IGC), a module inserted into a frozen pretrained LLM (after layer 1 of Llama 3.1 8B) that extracts operands and operators from the LLM's intermediate activations at an anchor token, computes the exact arithmetic result via a non-differentiable calculator emulated on the GPU, and injects the result back through a gated output mapping. The authors train only the IGC's two submodules on synthetic data and report 98-99% accuracy on the BigBench Arithmetic benchmark, outperforming the previous best results from PaLM 535B and a same-size finetuning baseline, with an ablation suggesting the calculator is responsible for the improvement. The paper also claims the method is efficient, interpretable, avoids side effects on non-arithmetic tasks, and could be extended to other non-differentiable operations.

Significance. If the empirical claims hold up, this is a valuable result: it demonstrates that a small, modular, non-differentiable component can be trained to perform exact arithmetic inside an LLM in a single forward pass, without chain-of-thought or external tools, and it provides a head-to-head finetuning baseline and an ablation that strengthen the attribution of the gain to the calculator. The paper also offers a concrete path toward training such a module during pretraining, which is an interesting idea. However, the significance is currently limited by reproducibility concerns: no code is provided, no seed-level results or error bars are reported, and the accuracy of the learned input-extraction component is never directly measured. These omissions make it impossible to assess the reliability and generality of the central claim.

major comments (5)
  1. [Appendix B / Section 4] The manuscript states that code will be provided only upon acceptance and does not report hyperparameters, number of seeds, or per-seed results. Table 1 reports averages without variance, and Figure 4 shows multiple seeds but no numeric values. Because the headline claim is a reliability claim ('reliably achieves 98% to 99% across multiple training runs'), the absence of seed-level data and code prevents independent verification. Please provide the full experimental setup, seed-level accuracies with standard deviations, and release the code (or at least detailed pseudocode for all three submodules).
  2. [Section 4, 'Investigating Anomalies'] The end-to-end accuracy is the only metric reported; the digit-level and operand-level accuracy of the Input Mapping submodule is never reported. This matters because the Input Mapping is the only component that must generalize from synthetic training data to the benchmark's template and operand distribution, and the paper itself attributes the slightly lower division accuracy (98% vs 99%) to a distribution mismatch between the training and test operand generators. Please report the Input Mapping's extraction accuracy per subtask, quantify the distribution mismatch (e.g., by evaluating on the training distribution and on the benchmark distribution), and discuss the failure modes when extraction is incorrect.
  3. [Section 4, 'Alternate Templates'] The claim that 'we noticed no difference in performance between these templates' is made without reporting any numbers, template descriptions, or results. Since template variation directly stresses the Input Mapping's ability to identify operands and operators, this claim is load-bearing for the generality of the method. Please provide the set of templates used, per-template accuracies, and a comparison to the BigBench template.
  4. [Section 3.1, 'Gated Outputs'] The claim that the IGC 'causes no destructive interference in tasks where it is not needed' is supported only by an unspecific sentence saying the architecture was tested on non-arithmetic tasks. No task names, metrics, or before/after comparisons are given. Since avoiding side effects is one of the advertised advantages (Table 2), please report the non-arithmetic tasks and the model's performance on them with and without the IGC.
  5. [Section 4, 'Ablations'] The text reports that the IGC+shortcut hybrid has 'high variance' and 'final performance is overall lower than the pure IGC,' but no final accuracies are given. Because this ablation is the key evidence that the calculator, not the extra parameters, is responsible for the gain, please provide the final accuracy (mean and standard deviation) for each architecture shown in Figure 4.
minor comments (5)
  1. [Table 1 and text] The model name 'PALM' should be written as 'PaLM' for consistency with the cited reference (Chowdhery et al., 2023).
  2. [Table 2] The symbol '#' is used in the table without a legend; please define it (presumably meaning 'partially' or 'depends on the task').
  3. [Figure 2 caption] The caption contains 'afterTt' with a missing space; it should be 'after T_t'.
  4. [Throughout] The paper inconsistently spells 'finetuning' and 'fine-tuning'; please choose one form and use it consistently.
  5. [Section 8, Limitations] The statement that for larger numbers 'the LLM can still use the IGC as a very reliable approximator' is vague; please specify what behavior the model exhibits for inputs longer than the fixed maximum length.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the benchmark is external, the calculator is an exact non-trainable oracle, and no test-set information is fitted.

full rationale

The paper's central claim is an empirical evaluation, not a derivation. The IGC module combines a frozen LLM with a non-differentiable, exact calculator implemented as GPU tensor operations; the Input Mapping is trained with an auxiliary cross-entropy loss on synthetic data annotated with ground-truth operands and operators, and the Output Mapping is trained with teacher-forced exact calculator outputs. The BigBench Arithmetic benchmark is external to this training loop: the paper does not fit any parameter to benchmark answers, and it explicitly notes in Section 4, 'Investigating Anomalies', that the benchmark's division operands follow a different generation algorithm than the synthetic training data, which would not be possible if test data were being used to tune the system. No assertion in the paper reduces by definition to its own inputs: the calculator's exactness is an implementation choice, not an inference from the benchmark results; the accuracy numbers are measured, not derived from the architecture's assumptions. The references to prior work are background context (Toolformer, adapters, chain-of-thought, tokenization analyses) and none is a load-bearing self-citation; in particular, no uniqueness theorem from the authors' own prior papers is invoked. The reported limitations—fixed maximum input length, deferred code release, and the unexplained distribution sensitivity of the division subtask—concern generalization and reproducibility, not circularity. The weakest point, that Input Mapping extraction accuracy is never directly reported, is a legitimate correctness risk but remains an empirical robustness concern rather than a case of the prediction being equivalent to its inputs.

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

The central claim depends on a small number of architectural choices and empirical regularities (tokenization, anchor token semantics, exact GPU arithmetic, distribution match). No free parameters in the physics sense are introduced; the listed items are engineered design choices. No new natural entities are posited.

free parameters (3)
  • Maximum number length = 10 digits
    The calculator uses a fixed-width representation with 10 digit positions, chosen to accommodate the benchmark's 5-digit operands and 10-digit results. This is an ad hoc architectural bound, not derived from the task.
  • Anchor layer = Layer 1
    The IGC is inserted after layer 1 of the frozen Llama 3.1 8B; the authors state they tried several layers and found early layers best. This is an empirical tuning choice.
  • Input/output alignment direction = Left-aligned with placeholder symbol
    The internal digit representation is left-aligned (most significant digit at a fixed index) with an 11th class for placeholders. This was chosen after right-aligned variants failed to converge, and is fitted to Llama's tokenization.
assumptions (4)
  • domain assumption Llama 3.1 8B tokenizes numbers left-to-right in chunks of up to three digits with a predictable token-to-digit mapping.
    Section A analyzes tokenization and builds the left-aligned architecture on this observation. If tokenization were different, the module design would need to change.
  • ad hoc to paper The anchor token (the switch from user to system in the chat template) reliably marks the point at which the complete arithmetic expression is available.
    Section 3.1 states the module is executed 'when the chat switches from the user to the system.' This is specific to the template used for training and evaluation, and may not generalize to free-form text.
  • domain assumption GPU tensor operations on integers up to 10 digits are exact (no overflow or rounding).
    Section B.2 notes that torch tensors are used and that the calculation is limited to 10 digits for numerical accuracy. This holds for the benchmark but is an implementation assumption.
  • domain assumption The synthetic training data and the benchmark test data are close enough in distribution that the learned Input Mapping generalizes, despite different random operand-generation algorithms.
    Section 4 'Investigating Anomalies' attributes the slightly lower division accuracy to a distribution mismatch. The assumption that this mismatch is minor is load-bearing for the near-perfect accuracy claim.

how reviews work

0 comments
Cite this review

Pith. "Pith review of IGC: Integrating a Gated Calculator into an LLM to Solve Arithmetic Tasks Reliably and Efficiently." pith.science (2026). https://pith.science/paper/B55W6GWM

@misc{pith2026250100684,
  author       = {Pith},
  title        = {Pith review of: IGC: Integrating a Gated Calculator into an LLM to Solve Arithmetic Tasks Reliably and Efficiently},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/B55W6GWM}},
  note         = {Machine review of arXiv:2501.00684}
}
read the original abstract

Solving arithmetic tasks is a simple and fundamental skill, yet modern Large Language Models (LLMs) have great difficulty with them. We introduce the Integrated Gated Calculator (IGC), a module that enables LLMs to perform arithmetic by emulating a calculator on the GPU. We finetune a Llama model with our module and test it on the BigBench Arithmetic benchmark, where it beats the State of the Art, outperforming all models on the benchmark, including models almost two orders of magnitude larger. Our approach takes only a single iteration to run and requires no external tools. It performs arithmetic operations entirely inside the LLM without the need to produce intermediate tokens. It is computationally efficient, interpretable, and avoids side-effects on tasks that do not require arithmetic operations. It reliably achieves 98\% to 99\% accuracy across multiple training runs and for all subtasks, including the substantially harder subtask of multiplication, which was previously unsolved.

Figures

Figures reproduced from arXiv: 2501.00684 by the authors.

Figure 1
Figure 1. Examples of arithmetic tasks. The Impact of Number Representations. The arithmetic abilities of LLMs strongly depend on the way numbers are represented (Thawani et al., 2021). McLeish et al. (2024) improve arithmetic performance by adding positional encodings to numbers. Similarly, Liu and Low (2023) show that good performance can be achieved on addition and subtraction tasks using finetuning only, and they attribut… view at source ↗
Figure 2
Figure 2. Left. The IGC is inserted into a pretrained LLM after a fixed layer, in this case layer 1. It modifies the output produced by that layer. Right. During training, the IGC takes the latent activations produced by the layer as its inputs and splits them into two parts: Before and after the anchor token Tt at time step t, which has a special role for argument selection. The IGC comprises three components, two of which a… view at source ↗
Figure 3
Figure 3. Left. The Input Mapping submodule takes variable-length textual embeddings and extracts the numbers and operator as fixed-length categorical data. The operands and operator are produced as probability distributions over possible digit values for each digit. Calculator (not shown). The calculator discretizes the distributions produced by the Input Mapping submodule by sampling the most probable number and operator. I… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: The accuracy of various architectures on the [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 2 canonical work pages

  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]

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report. arXiv preprint arXiv:2303.08774

    arXiv 2023

  4. [4]

    BIG bench authors. 2023. https://openreview.net/forum?id=uyTL5Bvosj Beyond the imitation game: Quantifying and extrapolating the capabilities of language models . Transactions on Machine Learning Research

    2023

  5. [5]

    Tom B Brown. 2020. Language models are few-shot learners. arXiv preprint arXiv:2005.14165

    arXiv 2020

  6. [6]

    Wenhu Chen, Xueguang Ma, Xinyi Wang, and William W Cohen. 2022. Program of thoughts prompting: Disentangling computation from reasoning for numerical reasoning tasks. arXiv preprint arXiv:2211.12588

    arXiv 2022

  7. [7]

    Aakanksha Chowdhery, Sharan Narang, Jacob Devlin, Maarten Bosma, Gaurav Mishra, Adam Roberts, Paul Barham, Hyung Won Chung, Charles Sutton, Sebastian Gehrmann, et al. 2023. Palm: Scaling language modeling with pathways. Journal of Machine Learning Research, 24(240):1--113

    2023

  8. [8]

    Hyung Won Chung, Le Hou, Shayne Longpre, Barret Zoph, Yi Tay, William Fedus, Yunxuan Li, Xuezhi Wang, Mostafa Dehghani, Siddhartha Brahma, et al. 2024. Scaling instruction-finetuned language models. Journal of Machine Learning Research, 25(70):1--53

    2024

Show all 31 references
  1. [9]

    Karl Cobbe, Vineet Kosaraju, Mohammad Bavarian, Mark Chen, Heewoo Jun, Lukasz Kaiser, Matthias Plappert, Jerry Tworek, Jacob Hilton, Reiichiro Nakano, Christopher Hesse, and John Schulman. 2021. Training verifiers to solve math word problems. arXiv preprint arXiv:2110.14168

    2021 arXiv

  2. [10]

    Ning Ding, Yujia Qin, Guang Yang, Fuchao Wei, Zonghan Yang, Yusheng Su, Shengding Hu, Yulin Chen, Chi-Min Chan, Weize Chen, et al. 2022. Delta tuning: A comprehensive study of parameter efficient methods for pre-trained language models. arXiv preprint arXiv:2203.06904

    2022 arXiv

  3. [11]

    Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. 2024. The llama 3 herd of models. arXiv preprint arXiv:2407.21783

    2024 arXiv

  4. [12]

    Nouha Dziri, Ximing Lu, Melanie Sclar, Xiang Lorraine Li, Liwei Jiang, Bill Yuchen Lin, Sean Welleck, Peter West, Chandra Bhagavatula, Ronan Le Bras, et al. 2024. Faith and fate: Limits of transformers on compositionality. Advances in Neural Information Processing Systems, 36

    2024

  5. [13]

    Luyu Gao, Aman Madaan, Shuyan Zhou, Uri Alon, Pengfei Liu, Yiming Yang, Jamie Callan, and Graham Neubig. 2023. Pal: Program-aided language models. In International Conference on Machine Learning, pages 10764--10799. PMLR

    2023

  6. [14]

    Lee Garreth. 2024. Tweet. https://x.com/garrethleee/status/1860039446311371132. A tweet about a paper, not yet published as of the time of this writing

    2024

  7. [15]

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

    2021

  8. [16]

    Neil Houlsby, Andrei Giurgiu, Stanislaw Jastrzebski, Bruna Morrone, Quentin De Laroussilhe, Andrea Gesmundo, Mona Attariyan, and Sylvain Gelly. 2019. Parameter-efficient transfer learning for nlp. In International conference on machine learning, pages 2790--2799. PMLR

    2019

  9. [17]

    Shima Imani, Liang Du, and Harsh Shrivastava. 2023. https://arxiv.org/abs/2303.05398 Mathprompter: Mathematical reasoning using large language models . Preprint, arXiv:2303.05398

    2023 arXiv

  10. [18]

    Jeonghwan Kim, Giwon Hong, Kyung-min Kim, Junmo Kang, and Sung-Hyon Myaeng. 2021. Have you seen that number? investigating extrapolation in question answering models. In Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing, pages 7031--7037

    2021

  11. [19]

    Lee, Kangwook Lee, and Dimitris Papailiopoulos

    Nayoung Lee, Kartik Sreenivasan, Jason D. Lee, Kangwook Lee, and Dimitris Papailiopoulos. 2023. https://arxiv.org/abs/2307.03381 Teaching arithmetic to small transformers . Preprint, arXiv:2307.03381

    2023 arXiv

  12. [20]

    u ttler, Mike Lewis, Wen-tau Yih, Tim Rockt \

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich K \"u ttler, Mike Lewis, Wen-tau Yih, Tim Rockt \"a schel, et al. 2020. Retrieval-augmented generation for knowledge-intensive nlp tasks. Advances in Neural Information Proc...

    2020

  13. [21]

    Tiedong Liu and Bryan Kian Hsiang Low. 2023. https://arxiv.org/abs/2305.14201 Goat: Fine-tuned llama outperforms gpt-4 on arithmetic tasks . Preprint, arXiv:2305.14201

    2023 arXiv

  14. [22]

    Sean McLeish, Arpit Bansal, Alex Stein, Neel Jain, John Kirchenbauer, Brian R Bartoldson, Bhavya Kailkhura, Abhinav Bhatele, Jonas Geiping, Avi Schwarzschild, et al. 2024. Transformers can do arithmetic with the right embeddings. arXiv preprint arXiv:2405.17399

    2024 arXiv

  15. [23]

    Maxwell Nye, Anders Johan Andreassen, Guy Gur-Ari, Henryk Michalewski, Jacob Austin, David Bieber, David Dohan, Aitor Lewkowycz, Maarten Bosma, David Luan, et al. 2021. Show your work: Scratchpads for intermediate computation with language models. arXiv preprint arXiv:2112.00114

    2021 arXiv

  16. [24]

    Changle Qu, Sunhao Dai, Xiaochi Wei, Hengyi Cai, Shuaiqiang Wang, Dawei Yin, Jun Xu, and Ji-Rong Wen. 2024. Tool learning with large language models: A survey. arXiv preprint arXiv:2405.17935

    2024 arXiv

  17. [25]

    Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023. https://arxiv.org/abs/2302.04761 Toolformer: Language models can teach themselves to use tools . Preprint, arXiv:2302.04761

    2023 arXiv

  18. [26]

    Avijit Thawani, Jay Pujara, Pedro A Szekely, and Filip Ilievski. 2021. Representing numbers in nlp: a survey and a vision. arXiv preprint arXiv:2103.13136

    2021 arXiv

  19. [27]

    Romal Thoppilan, Daniel De Freitas, Jamie Hall, Noam Shazeer, Apoorv Kulshreshtha, Heng-Tze Cheng, Alicia Jin, Taylor Bos, Leslie Baker, Yu Du, et al. 2022. Lamda: Language models for dialog applications. arXiv preprint arXiv:2201.08239

    2022 arXiv

  20. [28]

    Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timoth \'e e Lacroix, Baptiste Rozi \`e re, Naman Goyal, Eric Hambro, Faisal Azhar, et al. 2023. Llama: Open and efficient foundation language models. arXiv preprint arXiv:2302.13971

    2023 arXiv

  21. [29]

    Alex Wang, Amanpreet Singh, Julian Michael, Felix Hill, Omer Levy, and Samuel R. Bowman. 2019. https://arxiv.org/abs/1804.07461 Glue: A multi-task benchmark and analysis platform for natural language understanding . Preprint, arXiv:1804.07461

    2019 arXiv

  22. [30]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, and Denny Zhou. 2023. https://arxiv.org/abs/2201.11903 Chain-of-thought prompting elicits reasoning in large language models . Preprint, arXiv:2201.11903

    2023 arXiv

  23. [31]

    Zheng Yuan, Hongyi Yuan, Chuanqi Tan, Wei Wang, and Songfang Huang. 2023. How well do large language models perform in arithmetic tasks? arXiv preprint arXiv:2304.02015

    2023 arXiv

Pith tools

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