Pith. sign in

REVIEW 3 major objections 5 minor 55 references

TabulaX: Leveraging Large Language Models for Multi-Class Table Transformations

T0 review · 3 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Pith's one-line read The paper claims that a framework which classifies table mismatches into four types and then applies a tailored LLM generator beats specialized string-only and fuzzy-join systems on four benchmarks while returning human-readable Python or…

desk verdict A genuinely useful multi-class table transformation framework with an evaluation protocol that, as written, makes the headline F1 numbers upper bounds rather than reliable estimates. read the letter →

arxiv 2411.17110 v2 pith:K2LVLBS6 submitted 2024-11-26 cs.DB cs.LG

classification cs.DBcs.LG
keywords tabulardatatransformationheterogeneoustablejoinlargelanguagemodelsprogrammingbyexampleinterpretabletransformationschain-of-thoughtpromptingintegrationmulti-classclassification
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

TabulaX sets out to show that example-driven table transformation, converting values in a source column into the format of a target column so two tables can be joined, can be handled across a wide range of mismatch types by first classifying the mismatch and then applying a tailored generator. The four classes are string-based, numerical, algorithmic, and general (requiring outside knowledge), and for the first three the framework emits an explicit Python function or numeric formula that a user can inspect, verify, and edit. Only the general class relies on opaque LLM predictions over a lookup constructed from the model's knowledge. On four public benchmarks the framework reports F1 scores of 0.983, 0.952, 0.918, and 0.567, ahead of the string-only and fuzzy-join baselines it compares against. If correct, this means a general-purpose LLM plus a small classification layer can cover a broader class of transformations than specialized search engines while returning interpretable mappings.

What carries the argument

The load-bearing mechanism is the class-routing architecture: a serialization convention that presents example pairs as source-arrow-target strings, an LLM classifier that dispatches each table pair to one of four modules, and modules specialized per class. Numeric transformations are handled by Levenberg-Marquardt curve fitting over four function families, with the lowest-MSE function selected and then rendered as Python. String-based transformations use an LLM prompted with Input and Expected output test cases to write a Python function, verified by a syntax checker. Algorithmic transformations split the task into relationship tagging, aided by chain-of-thought prompting, followed by Python generation. General transformations use column-type detection followed by an LLM-constructed lookup, with the known weaknesses of hallucination, per-row cost, and non-interpretability. Downstream joining tolerates small mismatches by edit-distance matching for text and absolute difference for numbers.

What would settle it

Hold out the n example rows from the F1 computation and lock the prompt for each class before seeing the four benchmarks; if the TT and KBWT F1 gaps over DTT and GXJoin collapse, the claim that TabulaX's accuracy reflects generalization rather than selection and benchmark-derived few-shot examples is false.

Watch

Extended reading notes

Core claim

The paper's central discovery claim is that the difficulty in table transformation lies less in finding a transformation than in knowing which kind of transformation is needed, and that a classifier routing each table pair to a dedicated generator solves the multi-class problem better than a single model trying to do everything. Given a small set of matched rows, the classifier assigns the pair to one of four classes; numeric pairs go to curve fitting with mean-square-error selection among linear, polynomial, exponential, and rational forms; string pairs go to LLM-written Python code; algorithmic pairs go through a chain-of-thought relationship tagger and then Python generation; general pairs go to an LLM-based lookup. The framework reports that this design consistently achieves higher or comparable F1-scores than DTT, GXJoin, AFJ, and Explain-Da-V on the WT, SS, TT, and KBWT benchmarks, and that it produces interpretable transformation functions for all classes except general. It also reports that the classifier, although imperfect (macro F1 of 0.84 with its best model), costs little end-to-end: results with ground-truth class labels are close to those with LLM classification.

Load-bearing premise

The load-bearing premise is that choosing the best of 3-5 prompt variants per class, using a few-shot example drawn from the benchmark being tested, and not excluding the n example rows from the reported F1 still yields a fair measure of how TabulaX generalizes to unseen table pairs.

Editorial extensions

If this is right

  • String-only baselines can be outperformed on mixed benchmarks by adding a numeric curve-fitting module and a chain-of-thought algorithmic generator rather than relying on one model to handle every case.
  • Interpretable transformation functions are achievable without a domain-specific language: Python functions and numeric formulas can be read, edited, and executed once per column for string, numeric, and algorithmic classes.
  • The general class is the remaining accuracy bottleneck, with F1 of 0.567 on KBWT, driven by the model's internal knowledge limits and by one-to-many mappings.
  • Edit-distance matching buys a large recall increase with minimal precision loss, so the same generated functions support both heterogeneous joins and exact-match tasks such as imputation.

Reading between the lines

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

  • My inference: the reported gains should be retested with prompts frozen per class before seeing the benchmarks and with the n example rows excluded from scoring; until then the headline F1 gap over DTT and GXJoin may partly reflect tuning rather than transfer.
  • My inference: the class-routing design extends naturally to multi-column transformations, where each column pair is classified and transformed separately and the results are reconciled, a combination the paper leaves for future work.
  • My inference: the general class could be made both more accurate and more scalable by replacing the LLM lookup with retrieval from a knowledge base or bridge table, directly addressing the hallucination and per-row-cost limitations the paper lists.
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 / 5 minor

Summary. The paper proposes TabulaX, a framework that uses large language models for multi-class column-level table transformations. A classifier routes input column pairs into four classes—string-based, numerical, algorithmic, and general—and each class is handled by a tailored module: Python function generation for string transformations, curve fitting with Levenberg-Marquardt for numerical transformations, chain-of-thought relationship tagging plus code generation for algorithmic transformations, and LLM-constructed lookup for general transformations. The system is evaluated on four benchmarks (WT, SS, TT, KBWT) against DTT, GXJoin, AFJ, and Explain-Da-V, reporting F1 scores of 0.983, 0.952, 0.918, and 0.567 respectively, with interpretable transformation functions for all classes except general. The authors also release the code and datasets.

Significance. If the reported results are trustworthy, the paper makes a useful empirical contribution: it shows that an off-the-shelf LLM, combined with lightweight class routing and module-specific prompting, can outperform specialized programming-by-example and transformer baselines on heterogeneous join tasks while emitting human-readable Python transformations. The explicit release of code/datasets, the runtime analysis comparing LLM call counts, and the candid discussion of the general-transformation class limitations are strengths. However, the central claim is an F1 comparison, and the evaluation protocol as currently described does not establish that the reported numbers measure generalization on fresh table pairs.

major comments (3)
  1. [§5.2, Table 3] Prompt selection is performed on the same benchmarks used for the reported F1 scores. Section 5.2 states that "For each transformation class, we tested 3–5 prompt variants and selected the best-performing one for our experiments," and Section 4.2 similarly says the authors "try 3-5 prompts before selecting one." No independent prompt-validation split is described. Under this protocol, the reported F1 is an optimistic upper bound that includes test-set prompt selection. Please report results for all prompt variants, or use a held-out prompt-development set and report only the F1 obtained by the prompt selected without access to the test benchmarks.
  2. [§5.2, Table 3] The paper defines n input examples but never states whether those n rows are removed from the source column before precision, recall, and F1 are computed. If they are not removed, the TT dataset (average about 8 rows, n=3) has up to 37.5% of its rows trivially correct because the example rows are given in the prompt, and WT/KBWT (n=5 of roughly 92–113 rows) receive a recall boost of about 4–6%. This bears directly on the headline TT gap (0.918 vs. 0.643 for DTT). Please clarify the scoring protocol explicitly and report results both with and without the example rows included.
  3. [§4.5, §5.6] The relationship-tagging prompt for algorithmic transformations includes an in-context example of Gregorian-to-Jalali date conversion. The TT benchmark is predominantly algorithmic, and Section 5.6 itself discusses the difficulty of Gregorian-to-Hijri date transformations in the algorithmic class. If TT contains date-conversion tables of this type, the supplied few-shot example directly reveals the expected transformation relationship, inflating the algorithmic-class results on TT. Please either remove this overlapping example from the deployed prompt and rerun the TT experiments, or provide a per-relationship breakdown showing that TT date-conversion tables are not benefiting from the in-context example.
minor comments (5)
  1. [Tables 2 and 5] The support counts in the class-wise tables sum to 448 (207+60+105+76), while the dataset descriptions in Section 5.1 sum to 450 table pairs (31+108+230+81). Please reconcile these counts or explain the discrepancy.
  2. [Table 6] The GPT-4o rows in Table 6 are identical to the "Golden" classification rows in Table 4, yet Section 5.7 presents Table 6 as an evaluation of different model sizes without stating which classification setting is used. Please state explicitly whether the model-size experiments use the LLM classifier or the golden classifier.
  3. [Eq. (1)] Equation (1) is not syntactically well-formed: the expression "∀s_j∈S'((s_j, f(s_j)∈ E)" mixes set membership and the tuple notation, and the intended condition is unclear. Please rewrite it as a clean formal statement.
  4. [§5.6] There is a grammatical error in the sentence "the generated code may is incomplete," and the contributions section contains the typo "reproducability." These should be corrected.
  5. [§5.4] The comparison "TDE reports a coverage of 72% on TT, whereas our method achieves a recall of 92%" compares two different metrics; coverage and recall are not interchangeable. Please clarify how the TDE coverage number translates to the precision/recall framework used for the other baselines.

Circularity Check

3 steps flagged · score 6.0 of 10

Reported F1 is an upper bound: prompt variants are selected on the test benchmarks, example rows may remain in the scored source rows (making them correct by Eq. 1), and the algorithmic tagger's in-context Gregorian-to-Jalali example overlaps TT's calendar-conversion class.

  1. fitted input called prediction [Section 5.2 (Experimental Setup), Table 3 / Section 5.4]
    "For each transformation class, we tested 3–5 prompt variants and selected the best-performing one for our experiments."

    The prompt is part of the model. Selecting the variant with the highest performance on the same four benchmarks that are later reported in Table 3 makes the headline F1 a maximum over prompt variants rather than an independent estimate. No held-out prompt-validation split is described, so the advertised comparison against DTT, GXJoin, AFJ, and Explain-Da-V is fitted to the test set by construction.

  2. self definitional [Section 3, Eq. (1); Section 5.2 (input examples and recall definition)]
    "For a small subset S′⊂ S, let E ={(s_i,t_j)|s_i ∈ S′} denote a set of examples where target values are provided to guide the transformation process. We want to find a transformation function f such that: f :S→T | ∀s_j∈S′((s_j,f(s_j)) ∈ E. (1)"

    Equation (1) forces the learned transformation to reproduce every example pair in E. The protocol reports recall over 'source rows' and never states that the n example rows are removed from the source column before scoring. Since E ⊆ S by definition, any scored example row is correct by construction, not by prediction. This matters most on TT, where n=3 and tables average only 8 rows, so the in-sample share of recall can be large.

1 more flagged steps
  1. other [Section 4.5 (Algorithmic Transformations); cf. Section 5.1 (TT) and Section 5.6 (error analysis)]
    "given the input ("2024/09/05" -> "1403/06/16"), ("1886/06/27" -> "1265/04/06"), the model is expected to return Gregorian date to Jalali (Solar Hijri) date . This transformation is included in the training examples provided for in-context learning"

    The relationship tagger for algorithmic transformations is prompted with a Gregorian-to-Jalali calendar conversion as a training example. TT, the benchmark used for the algorithmic-heavy F1 comparison, contains 102 algorithmic transformations, and the paper's own error analysis discusses 'transforming Gregorian dates to Hijri dates' in that benchmark. For any TT table in this calendar-conversion class, the expected relationship label is effectively supplied by the in-context prompt rather than inferred from the input examples, making part of the reported algorithmic performance a form of test-set leakage.

full rationale

TabulaX is an empirical systems paper, not a formal derivation, so circularity appears as fitted evaluation rather than as a theorem reducing to its assumptions. The most load-bearing issue is prompt selection: Section 5.2 admits that 3–5 prompt variants were tried per class and the best one was kept, with no validation split, so the F1 numbers in Table 3 are maxima over prompts on the same benchmarks. Second, Eq. (1) defines E as the training pairs, and Sections 5.2/4.8 define evaluation over source rows without explicitly excluding E; if example rows are scored, they are correct by construction (especially on TT with n=3 of ~8 rows). Third, the in-context relationship example 'Gregorian date to Jalali (Solar Hijri) date' sits in the same calendar-conversion family as the TT algorithmic tables discussed in Section 5.6, so the tagger's answer for those tables may be leaking from the prompt. These are protocol flaws rather than self-citation chains: the authors' own DTT/GXJoin papers appear as baselines, not as authority for TabulaX's claims, so no self-citation circularity is present. The score is 6 because the central headline comparison is partly reduced by construction: the reported F1 is an upper bound whose size cannot be assessed without a proper held-out prompt selection procedure and explicit exclusion of example rows.

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

No new physical or conceptual entities are postulated; the four transformation classes are a categorization, not an invented object with a falsifiable handle. The free parameters are the per-table curve-fitting coefficients, the hand-set example count, the hand-selected function families, and the post-hoc chosen prompt variants.

free parameters (4)
  • Numeric curve-fitting coefficients (a, b, c) = per-table values, e.g., a approximately 0.45 in the pounds-to-kilograms example
    The numerical module fits up to four candidate families (linear, quadratic, exponential, rational) to the n example pairs with Levenberg-Marquardt and selects the lowest-MSE function (Section 4.3). These per-table parameters are central to the numeric class results (F1 0.971).
  • Number of examples n = 5 for WT/SS/KBWT, 3 for TT
    Chosen by hand in Section 5.2; performance is sensitive to n, and no sensitivity analysis is reported.
  • Candidate function family set = linear, quadratic, exponential, rational
    Hand-selected in Section 4.3; the framework's ability to capture a numeric mapping is bounded by this set.
  • Prompt variants per class = best of 3-5 tested prompts
    Authors report testing 3-5 prompt variants and keeping the best (Sections 4.2, 5.2). This is a post-hoc selection that affects all class-specific results.
assumptions (5)
  • domain assumption A small set of n example pairs is sufficient to infer a transformation function that generalizes to the rest of the source column
    Problem formulation in Section 3 assumes f learned from S' applies to all of S; Section 5.6 acknowledges this fails when examples are not representative (e.g., middle names).
  • domain assumption No schema or metadata is available; transformations are inferred from cell values alone
    Stated in Section 3: 'we operate under the assumption that no metadata or schema is available'.
  • domain assumption LLMs can reliably classify, generate correct Python code, and supply world knowledge when prompted appropriately
    The whole framework depends on this; the paper tests it empirically (Tables 2, 3, 6) but does not prove it; Section 4.6 acknowledges hallucinations.
  • domain assumption The manual class labels for the 448 benchmark instances are correct
    Section 5.3: labels were annotated by the authors with an 8% conflict rate resolved by discussion; classifier accuracy is measured against these labels.
  • ad hoc to paper The benchmarks used (WT, SS, TT, KBWT) have not been memorized by GPT-4o in a way that inflates performance
    The general module answers by querying the LLM's parametric knowledge (Section 4.6); KBWT is built from knowledge-base tables (Section 5.1), so the measured F1 may partly reflect memorization rather than transformation discovery. The paper does not test for contamination.

how reviews work

0 comments
Cite this review

Pith. "Pith review of TabulaX: Leveraging Large Language Models for Multi-Class Table Transformations." pith.science (2026). https://pith.science/paper/K2LVLBS6

@misc{pith2026241117110,
  author       = {Pith},
  title        = {Pith review of: TabulaX: Leveraging Large Language Models for Multi-Class Table Transformations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K2LVLBS6}},
  note         = {Machine review of arXiv:2411.17110}
}
read the original abstract

The integration of tabular data from diverse sources is often hindered by inconsistencies in formatting and representation, posing significant challenges for data analysts and personal digital assistants. Existing methods for automating tabular data transformations are limited in scope, often focusing on specific types of transformations or lacking interpretability. In this paper, we introduce TabulaX, a novel framework that leverages Large Language Models (LLMs) for multi-class column-level tabular transformations. TabulaX first classifies input columns into four transformation types (string-based, numerical, algorithmic, and general) and then applies tailored methods to generate human-interpretable transformation functions, such as numeric formulas or programming code. This approach enhances transparency and allows users to understand and modify the mappings. Through extensive experiments on real-world datasets from various domains, we demonstrate that TabulaX outperforms existing state-of-the-art approaches in terms of accuracy, supports a broader class of transformations, and generates interpretable transformations that can be efficiently applied.

Figures

Figures reproduced from arXiv: 2411.17110 by the authors.

Figure 1
Figure 1. Example input tables with formatting mismatch [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The architecture of our framework 52], and some retrieve mapping functions from large code reposi￾tories [18, 20]. One may argue that recent commercially available LLMs, such as GPT and Gemini, could address these challenges. To evaluate the performance of LLMs in this context, we conducted an experiment using the GPT model4 on our benchmark consisting of diverse real-world tables. However, the out-of-the-box model … view at source ↗
Figure 1
Figure 1. It is important to note that nominal numbers, such [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figures from the paper (1 more)
Figure 3
Figure 3. Figure 3: The steps of processing an arbitrary input table [PITH_FULL_IMAGE:figures/full_fig_p007_3.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

55 extracted references · 47 canonical work pages

  1. [1]

    Ilyas, Mourad Ouzzani, Paolo Papotti, and Michael Stonebraker

    Ziawasch Abedjan, John Morcos, Ihab F. Ilyas, Mourad Ouzzani, Paolo Papotti, and Michael Stonebraker. 2016. DataXFormer: A robust transformation discovery system. In 2016 IEEE 32nd International Conference on Data Engineering (ICDE) . 1134–1145

  2. [2]

    Mehdi Akbarian Rastaghi, Ehsan Kamalloo, and Davood Rafiei. 2022. Probing the Robustness of Pre-trained Language Models for Entity Matching. InProceedings of the 31st ACM International Conference on Information & Knowledge Management . 3786–3790

  3. [3]

    Rajeev Alur, Dana Fisman, Rishabh Singh, and Armando Solar-Lezama. 2016. SyGuS-Comp 2016: Results and Analysis. Electronic Proceedings in Theoretical Computer Science 229 (Nov 2016), 178–202

  4. [4]

    Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel Ziegler, Jeffrey Wu, Clemens Winter, Chris Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gr...

  5. [5]

    Yu, Qiang Yang, and Xing Xie

    Yupeng Chang, Xu Wang, Jindong Wang, Yuan Wu, Linyi Yang, Kaijie Zhu, Hao Chen, Xiaoyuan Yi, Cunxiang Wang, Yidong Wang, Wei Ye, Yue Zhang, Yi Chang, Philip S. Yu, Qiang Yang, and Xing Xie. 2024. A Survey on Evaluation of Large Language Models. ACM Trans. Intell. Syst. Technol. 15, 3, Article 39 (March 2024), 45 pages

  6. [6]

    Wenhu Chen, Ming-Wei Chang, Eva Schlinger, William Wang, and William W Cohen. 2020. Open question answering over tables and text. arXiv preprint arXiv:2010.10439 (2020)

  7. [7]

    Arash Dargahi Nobari and Davood Rafiei. 2022. Efficiently Transforming Tables for Joinability. In 2022 IEEE 38th International Conference on Data Engineering (ICDE). IEEE, 1649–1661

  8. [8]

    Arash Dargahi Nobari and Davood Rafiei. 2024. DTT: An Example-Driven Tabular Transformer for Joinability by Leveraging Large Language Models. Proc. ACM Manag. Data (SIGMOD) 2, 1, Article 24 (March 2024), 24 pages

Show all 55 references
  1. [9]

    Dong Deng, Guoliang Li, Shuang Hao, Jiannan Wang, and Jianhua Feng. 2014. MassJoin: A mapreduce-based method for scalable string similarity joins. In 2014 IEEE 30th International Conference on Data Engineering . 340–351

  2. [10]

    Xiang Deng, Huan Sun, Alyssa Lees, You Wu, and Cong Yu. 2020. TURL: Table Understanding through Representation Learning. Proc. VLDB Endow. 14, 3 (2020), 307–319

  3. [11]

    Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. 2019. BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. In Proceedings of the 2019 Conference of the North American Chapter of the Associ- ation for Computational Linguistics: Hum...

  4. [12]

    AnHai Doan, Alon Halevy, and Zachary Ives. 2012. Principles of data integration . Elsevier

  5. [13]

    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)

  6. [14]

    Sumit Gulwani. 2011. Automating String Processing in Spreadsheets Using Input-Output Examples. InProceedings of the 38th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (Austin, Texas, USA) (POPL ’11). Association for Computing Machinery, New York, N...

  7. [15]

    Harris, and Rishabh Singh

    Sumit Gulwani, William R. Harris, and Rishabh Singh. 2012. Spreadsheet Data Manipulation Using Examples. Commun. ACM 55, 8 (Aug. 2012), 97–105

  8. [16]

    Pu, Soheil Hassas Yeganeh, Renée J

    Oktie Hassanzadeh, Ken Q. Pu, Soheil Hassas Yeganeh, Renée J. Miller, Lucian Popa, Mauricio A. Hernández, and Howard Ho. 2013. Discovering linkage points over web data. Proc. VLDB Endow. 6, 6 (April 2013), 445–456

  9. [17]

    Jian He, Enzo Veltri, Donatello Santoro, Guoliang Li, Giansalvatore Mecca, Paolo Papotti, and Nan Tang. 2016. Interactive and deterministic data cleaning. In Proceedings of the 2016 International Conference on Management of Data. 893–907

  10. [18]

    Yeye He, Xu Chu, Kris Ganjam, Yudian Zheng, Vivek Narasayya, and Surajit Chaudhuri. 2018. Transform-data-by-example (TDE): an extensible search engine for data transformations. Proc. VLDB Endow. 11, 10 (2018), 1165–1177

  11. [19]

    Yeye He, Kris Ganjam, and Xu Chu. 2015. SEMA-JOIN: Joining Semantically- Related Tables Using Big Table Corpora. Proc. VLDB Endow. 8, 12 (Aug. 2015), 1358–1369

  12. [20]

    Yeye He, Kris Ganjam, Kukjin Lee, Yue Wang, Vivek Narasayya, Surajit Chaud- huri, Xu Chu, and Yudian Zheng. 2018. Transform-Data-by-Example (TDE): Extensible Data Transformation in Excel. In Proceedings of the 2018 Interna- tional Conference on Management of Data (Houston, TX,...

  13. [21]

    Hiroshi Iida, Dung Thai, Varun Manjunatha, and Mohit Iyyer. 2021. TABBIE: Pre- trained Representations of Tabular Data. In Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics: Hu- man Language Technologies. Associat...

  14. [22]

    Anderson, Michael Cafarella, and H

    Zhongjun Jin, Michael R. Anderson, Michael Cafarella, and H. V. Jagadish. 2017. Foofah: Transforming Data By Example. In Proceedings of the 2017 ACM Interna- tional Conference on Management of Data (Chicago, Illinois, USA) (SIGMOD ’17). Association for Computing Machinery, New...

  15. [23]

    Mihir Kale and Abhinav Rastogi. 2020. Text-to-Text Pre-Training for Data-to-Text Tasks. In Proceedings of the 13th International Conference on Natural Language Generation. Association for Computational Linguistics, Dublin, Ireland, 97–102. https://aclanthology.org/2020.inlg-1.14

  16. [24]

    Aamod Khatiwada, Roee Shraga, Wolfgang Gatterbauer, and Renée J Miller. 2022. Integrating data lake tables. Proceedings of the VLDB Endowment 16, 4 (2022), 932–945

  17. [25]

    Peng Li, Xiang Cheng, Xu Chu, Yeye He, and Surajit Chaudhuri. 2021. Auto- FuzzyJoin: Auto-Program Fuzzy Similarity Joins Without Labeled Examples. In Proceedings of the 2021 International Conference on Management of Data (Virtual Event, China) (SIGMOD/PODS ’21). Association fo...

  18. [26]

    Peng Li, Yeye He, Dror Yashar, Weiwei Cui, Song Ge, Haidong Zhang, Danielle Rifinski Fainman, Dongmei Zhang, and Surajit Chaudhuri. 2024. Table-GPT: Table Fine-tuned GPT for Diverse Table Tasks. Proc. ACM Manag. Data 2, 3, Article 176 (May 2024), 28 pages

  19. [28]

    Yuliang Li, Jinfeng Li, Yoshihiko Suhara, AnHai Doan, and Wang-Chiew Tan

  20. [29]

    Mingxing Liu, Junfeng Wang, Tao Lin, Quan Ma, Zhiyang Fang, and Yanqun Wu

  21. [30]

    Deep Entity Matching with Pre-Trained Language Models. Proc. VLDB Endow. 14, 1 (oct 2020), 50–60. https://doi.org/10.14778/3421424.3421431

  22. [31]

    Renée J Miller, Fatemeh Nargesian, Erkang Zhu, Christina Christodoulakis, Ken Q Pu, and Periklis Andritsos. 2018. Making Open Data Transparent: Data Discovery on Open Data. IEEE Data Eng. Bull. 41, 2 (2018)

  23. [32]

    Md Mahadi Hasan Nahid and Davood Rafiei. 2024. NormTab: Improving Sym- bolic Reasoning in LLMs Through Tabular Data Normalization. arXiv preprint arXiv:2406.17961 (2024)

  24. [33]

    Renée J Miller. 2018. Open data integration. Proceedings of the VLDB Endowment 11, 12 (2018), 2130–2139

  25. [34]

    Soroush Omidvartehrani, Arash Dargahi Nobari, and Davood Rafiei. 2024. GXJoin: Generalized Cell Transformations for Explainable Joinability. In Ad- vances in Databases and Information Systems. Springer Nature Switzerland, Cham, 123–137

  26. [35]

    Ankur Parikh, Xuezhi Wang, Sebastian Gehrmann, Manaal Faruqui, Bhuwan Dhingra, Diyi Yang, and Dipanjan Das. 2020. ToTTo: A Controlled Table-To-Text Generation Dataset. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP). Associatio...

  27. [36]

    Mohamed Nejjar, Luca Zacharias, Fabian Stiehle, and Ingo Weber. 2023. LLMs for science: Usage for code generation and data analysis. Journal of Software: Evolution and Process (2023), e2723

  28. [37]

    Ananth Ranganathan. 2004. The levenberg-marquardt algorithm. Tutoral on LM algorithm 11, 1 (2004), 101–110

  29. [38]

    Pranab Sahoo, Ayush Kumar Singh, Sriparna Saha, Vinija Jain, Samrat Mondal, and Aman Chadha. 2024. A systematic survey of prompt engineering in large language models: Techniques and applications. arXiv preprint arXiv:2402.07927 (2024)

  30. [39]

    Colin Raffel, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter J. Liu. 2020. Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer. Journal of Machine Learning Research 21 (2020), 140:1–140:67

  31. [40]

    Rishabh Singh. 2016. BlinkFill: Semi-Supervised Programming by Example for Syntactic String Transformations. Proc. VLDB Endow. 9, 10 (June 2016), 816–827

  32. [41]

    Yuan Sui, Mengyu Zhou, Mingjie Zhou, Shi Han, and Dongmei Zhang. 2024. Table Meets LLM: Can Large Language Models Understand Structured Table Data? A Benchmark and Empirical Study. In Proceedings of the 17th ACM Inter- national Conference on Web Search and Data Mining (Merida,...

  33. [42]

    Roee Shraga and Renée J Miller. 2023. Explaining dataset changes for semantic data versioning with explain-da-v. Proc. VLDB Endow. 16, 6 (2023)

  34. [43]

    James Thorne, Majid Yazdani, Marzieh Saeidi, Fabrizio Silvestri, Sebastian Riedel, and Alon Halevy. 2021. From natural language processing to neural databases. In Proc. VLDB Endow., Vol. 14. VLDB Endowment, 1033–1039. 13

  35. [44]

    Jianxun Wang and Yixiang Chen. 2023. A Review on Code Generation with LLMs: Application and Evaluation. In 2023 IEEE International Conference on Medical Artificial Intelligence (MedAI). 284–289

  36. [45]

    Nan Tang, Ju Fan, Fangyi Li, Jianhong Tu, Xiaoyong Du, Guoliang Li, Sam Madden, and Mourad Ouzzani. 2021. RPT: Relational Pre-Trained Transformer is Almost All You Need towards Democratizing Data Preparation. Proc. VLDB Endow. 14, 8 (2021), 1254–1261

  37. [46]

    Yue Wang and Yeye He. 2017. Synthesizing Mapping Relationships Using Table Corpus. In Proceedings of the 2017 ACM International Conference on Manage- ment of Data (Chicago, Illinois, USA) (SIGMOD ’17). Association for Computing Machinery, New York, NY, USA, 1117–1132

  38. [47]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, brian ichter, Fei Xia, Ed Chi, Quoc V Le, and Denny Zhou. 2022. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. In Advances in Neural Information Processing Systems, Vol. 35. Curran Associates, Inc....

  39. [48]

    Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoc Le, Ed Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. 2022. Self-consistency improves chain of thought reasoning in language models. arXiv preprint arXiv:2203.11171 (2022)

  40. [49]

    Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Tom Griffiths, Yuan Cao, and Karthik Narasimhan. 2023. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. In Advances in Neural Information Processing Systems , Vol. 36. Curran Associates, Inc., 11809–11822

  41. [50]

    Pengcheng Yin, Graham Neubig, Wen-tau Yih, and Sebastian Riedel. 2020. TaBERT: Pretraining for Joint Understanding of Textual and Tabular Data. In Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics. Association for Computational Linguistics...

  42. [51]

    Linting Xue, Aditya Barua, Noah Constant, Rami Al-Rfou, Sharan Narang, Mihir Kale, Adam Roberts, and Colin Raffel. 2022. ByT5: Towards a Token-Free Fu- ture with Pre-trained Byte-to-Byte Models. Transactions of the Association for Computational Linguistics 10 (03 2022), 291–306

  43. [52]

    Chen Zhao and Yeye He. 2019. Auto-EM: End-to-End Fuzzy Entity-Matching Using Pre-Trained Deep Models and Transfer Learning. In The World Wide Web Conference (San Francisco, CA, USA) (WWW ’19). Association for Computing Machinery, New York, NY, USA, 2413–2424

  44. [53]

    Erkang Zhu, Yeye He, and Surajit Chaudhuri. 2017. Auto-join: Joining tables by leveraging transformations. Proc. VLDB Endow. 10, 10 (2017), 1034–1045. 14

  45. [54]

    Tianshu Zhang, Xiang Yue, Yifei Li, and Huan Sun. 2023. Tablellama: Towards open large generalist models for tables. arXiv preprint arXiv:2311.09206 (2023)

  46. [2020]

    Deep Entity Matching with Pre-Trained Language Models. Proc. VLDB Endow. 14, 1 (sep 2020), 50–60

  47. [2024]

    Applied Sciences 14, 3 (2024)

    An Empirical Study of the Code Generation of Safety-Critical Software Using LLMs. Applied Sciences 14, 3 (2024)

Pith tools

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