Pith. sign in

REVIEW 3 major objections 6 minor 1 cited by

Are the Majority of Public Computational Notebooks Pathologically Non-Executable?

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

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

Pith's one-line read Most public notebooks that fail to run are misconfigured, not broken, and can be partially restored.

desk verdict The paper's real contribution is partial executability; its headline '21.3% pathological' number is an assumption, not a measurement, and the actual restoration data are much weaker. read the letter →

arxiv 2502.04184 v4 pith:7W4APHUA submitted 2025-02-06 cs.SE

Tien Nguyen , Waris Gill , Muhammad Ali Gulzar This is my paper · ORCID
classification cs.SE
keywords computationalnotebooksnon-executabilitynotebookrestorationLLM-basedrepairpartialexecutabilitymisconfigurationpublicreuseJupyter
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

Prior studies classify a notebook as executable only if it runs end-to-end without error, and have reported that roughly three-quarters of public notebooks fail that test. This paper argues that the binary notion is too rigid: a notebook that stops because an input file is missing or a module is uninstalled is not broken, only misconfigured, and can often be restored. Analyzing 42,546 popular public notebooks, the authors find 81.5% non-executable under the strict definition, but only 21.3% of non-executable notebooks are pathologically non-executable; the rest are executable or potentially restorable. They show that lightweight LLM-driven fixes—installing correct modules, generating synthetic input data, defining undefined names—fully restore 5.4% of previously non-executable notebooks and meaningfully improve partial executability of many others. The claim matters because it reframes notebook reuse: most failures are environmental, and even partially executable notebooks carry value.

What carries the argument

The machinery is a two-dimensional view of executability. First, a taxonomy: notebooks are executable, restorable (first error is a missing module, missing input file, or undefined name), or pathologically non-executable (all other unresolvable errors). Second, a degree-of-executability metric defined as the ratio of cells successfully executed before the first error to the total number of cells, turning a binary label into a continuum. The measurement pipeline executes each notebook with an automated notebook-runner in a per-repository virtual environment, records the first error, then iteratively applies targeted LLM-driven repairs—installing inferred module names, generating synthetic input data, or inserting definitions for undefined names—and re-executes to measure improvement. This combination lets the authors separate 'not runnable here' from 'not runnable anywhere' and quantify partial value.

What would settle it

Take a random sample of notebooks the paper labels pathologically non-executable (first error something like AttributeError, TypeError, or ValueError) and try to restore them after supplying the repository's complete dependency files and any available local data or execution order. If a substantial share then run to completion, the claim that only 21.3% of non-executable notebooks are pathological is too low. Conversely, if a large share of ModuleNotFound notebooks remain broken even after their modules install successfully, the 'restorable' category is too optimistic.

Watch

Extended reading notes

Core claim

The paper's central claim is that most public computational notebooks are not intrinsically broken. Under a strict 'as-is' execution, 81.5% of 42,546 popular notebooks fail; but of the 34,659 non-executable notebooks, only 21.3% (7,387) suffer errors the authors classify as pathological—syntax or indentation failures, attribute/type/value errors, and similar problems that require knowing the notebook's intended semantics to repair. The remaining non-executable notebooks fail because of missing modules, missing input files, or undefined names, which the authors treat as environmental or session-state issues rather than code defects. In support, installing the correct modules improves executability by 40.5% on average for notebooks where installation succeeds, LLM-generated synthetic input files fully or partially restore 37% of notebooks with FileNotFound errors, and LLM-generated definitions fix 45.3% of NameError notebooks. The conclusion is that executability should be measured on a continuum—cells executed before the first error divided by total cells—and evaluated within the interactive notebook paradigm, not by traditional atomic software standards.

Load-bearing premise

The load-bearing premise is that a notebook whose first error is a missing module, missing file, or undefined name is automatically 'restorable', while every other first error is 'pathologically non-executable'; the 21.3% headline follows from that classification, not from demonstrated restoration of most notebooks.

Editorial extensions

If this is right

  • Notebook non-executability is substantially lower than the commonly cited 76% figure when measured with a finer taxonomy: most failures are missing environments, not bad code.
  • Partial executability—the fraction of cells that run before the first error—should be reported alongside binary executability, since even pathological notebooks average 34.1% executable cells.
  • Lightweight LLM-driven restoration can recover full or partial execution for a meaningful share of notebooks: 5.4% fully restored, with average improvements of 40.5% from module installation and 28% from synthetic input generation.
  • Studies of notebook quality should stratify by popularity; NameError and other low-level errors concentrate in low-star notebooks, biasing earlier large-scale datasets.
  • Executability is a prerequisite for reproducibility, so restoration and partial execution open the door to dynamic analysis tools on notebooks previously dismissed as unusable.

Reading between the lines

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

  • The paper classifies every non-Module/File/Name first error as pathologically non-executable without attempting restoration for most of those error types; if AttributeError and TypeError notebooks were actually fixable, the pathological share could fall below 21.3%.
  • The 'restorable' label is assigned by error type rather than by demonstrated success; actual repair rates (21.5% for module installation, 37% for synthetic files) suggest that a fix-based definition would put the truly restorable share well below 78.7%.
  • The partial-executability metric could serve as a practical triage signal: notebooks with high partial execution are the cheapest repair targets, so repair effort should be prioritized there.
  • A natural testable extension is to run the same error-driven restoration with a different LLM or with multi-shot feedback; the paper's single-shot open-source LLM numbers may be a lower bound.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. The paper argues that prior estimates of notebook non-executability (e.g., 76%) are too pessimistic because they use a binary, strict notion of executability. It proposes a distinction between restorable notebooks (those failing only due to missing modules, input files, or undefined names) and pathologically non-executable notebooks (those with intrinsically unresolvable errors). The authors build a dataset of 42,546 popular public GitHub notebooks, execute them with Papermill, and report that 81.5% are non-executable as-is. Using a taxonomy based on the first error, they classify 21.3% of non-executable notebooks as pathological and 78.7% as potentially restorable. They then apply LLM-based restoration strategies for ModuleNotFound, FileNotFound, and NameError, reporting full restoration of 5.4% of non-executable notebooks and partial restoration of 12.8%, with improvements in cell-level executability for the partially restored cases. The paper also introduces a partial-executability metric and shows that even pathologically non-executable notebooks run, on average, 34.1% of their cells.

Significance. If the central claim held, the paper would substantially revise the accepted view that most public notebooks are non-executable, and it would provide a useful framework for separating environmental misconfiguration from intrinsic code breakage. The dataset construction with GitHub-star stratification, the public artifact, and the partial-executability metric are genuine contributions, as is the demonstration that LLM-based restoration can improve execution in a non-trivial fraction of cases. However, the headline number (21.3% pathological) is not an empirical measurement but a definitional consequence of the error taxonomy, and the paper's own restoration results show that the true rate of demonstrated restoration is much lower. The paper's framing therefore overstates the strength of the evidence, although the underlying measurement framework and partial results remain valuable if appropriately qualified.

major comments (3)
  1. [Section IV-A2 and Section V-B] The headline claim that only 21.3% of non-executable notebooks are pathologically non-executable is an arithmetic consequence of the taxonomy, not of the restoration experiments. In Section IV-A2, all notebooks whose first error is ModuleNotFound, FileNotFound, or NameError are categorized as restorable, and in Section V-B these 27,272 notebooks are counted as '78.7% restorable'. But Section V-D reports that only 3,760 of 23,476 ModuleNotFound notebooks (16.0%) had their modules successfully installed, and only 1,378 of 4,546 FileNotFound notebooks (30.3%) were fully or partially restored. Thus the 'restorable' label is an assumption about environmental misconfiguration, not a measured outcome. The paper should either redefine restorability in terms of demonstrated restoration success or explicitly present 78.7% as an upper bound on potentially restorable notebooks, with the restoration success rates reported separately. Without this change, the title's answer to the question 'Are the Majority ... Pathologically Non-Executable?' is not supported by the paper's own data.
  2. [Section IV-A2 (Papermill first-error logging)] The classification uses only the first error that halts execution, which overestimates restorability. A notebook whose first error is FileNotFound may, after the input file is generated, fail again with an AttributeError, ValueError, or other error that the taxonomy would classify as pathological. The restoration results in Section V-D demonstrate this: among the 23,476 ModuleNotFound notebooks, 13,746 failed for other reasons after installation attempts, and only a subset of those with valid modules were restored. The paper should report how many notebooks were attempted for each error type and how many of those failed again at later cells, and it should distinguish notebooks that were ultimately fully restored from those that only progressed to a different error. Using first-error categories as a proxy for restorability is only valid if the subsequent-error distribution is reported.
  3. [Section V-D vs. Abstract/Introduction] The paper reports inconsistent restoration success numbers. The abstract states that LLM-based methods improve executability by 42.7% for module installation and 28% for synthetic data, but Section V-D1 and the RQ4 takeaway report 40.5% for module installation. The introduction states that the fix 'fully restores full executability of 4,943 of the notebooks' for which the module and synthetic data were found, while the abstract and conclusion state that 5.4% of previously non-executable notebooks (which would be about 1,871 of 34,659) were fully restored. These numbers cannot all be correct. The authors should reconcile the count of fully restored notebooks, the percentage figures, and the improvement percentages, and ensure that the abstract, introduction, and results sections are consistent.
minor comments (6)
  1. [Section V-B, Takeaway RQ2] The takeaway says 'only 21.3% of all notebooks are pathologically non-executable', but 7,387 / 42,546 = 17.4%. The 21.3% figure refers to the percentage of non-executable notebooks, not all notebooks; this should be phrased precisely to avoid confusion.
  2. [Section V-D3 and Abstract] The NameError restoration success rate is reported differently: Section V-D3 says 45.3% of 404 notebooks improved and 8.7% fully restored, while the RQ4 takeaway lists a 9.4% improvement figure for NameError. The relationship between '45.3% improved' and '9.4%' is not explained; please clarify.
  3. [Section IV-A (sampling)] The description of the 13% sampling step is vague. After collecting approximately 318,000 notebooks, the authors 'take a 13% sample' but do not specify the sampling procedure (uniform random, stratified by repository, or something else). This matters for the generalizability of the 21.3% estimate and should be described precisely.
  4. [Section V-D2] The sentence 'the executability of 1,378 (37%) notebooks are fully or partially restored' should specify that 37% is the success rate among the 3,729 notebooks for which input files were generated, not among all 4,546 FileNotFound notebooks. This is stated in the surrounding text but the phrase is ambiguous.
  5. [Section VI, Threats to validity] The threat that 'an earlier fatal runtime error (that we cannot resolve) may hinder our ability to capture FileNotFound or ModuleNotFound errors' is acknowledged, but the same concern applies in the opposite direction for the restorable category: a first FileNotFound may mask later pathological errors. This should be stated explicitly in the threats section.
  6. [Introduction and Figure 10] The introduction claims a 95% executability improvement in the case study, and Figure 10 summarizes before/after executable notebook counts, but the figure is not described in the text beyond a one-line caption. Please add a sentence in Section V-D4 explaining what Figure 10 shows and how the before/after counts are derived.

Circularity Check

1 steps flagged · score 6.0 of 10

RQ2's 21.3%/78.7% split is definitional: the 'restorable' class is the error taxonomy itself, not a measured outcome.

  1. self definitional [Section IV-A2 (Dynamic Error Checking) and Section V-B (RQ2)]
    "We categorize the execution status of each notebook into the following groups: ... 2) FileNotFound: The notebook writes to or reads from a file or directory that is unavailable during execution. 3) ModuleNotFound: The notebook imports unavailable modules, packages, or libraries. 4) NameError: The notebook uses a variable, function, or class without defining or importing it. 5) Others/Non-Fixable: The notebook encounters errors not covered by the above categories. ... we find 7,387 (21.3%) pathologically non-executable notebooks ..."

    The 'restorable' group is defined as the union of error types 2-4, while everything else is labeled 'Others/Non-Fixable.' RQ2 then counts 27,272 notebooks in that group and reports them as restorable. The 78.7% figure is therefore a restatement of the taxonomy, not a measured property: no restoration attempt is required to enter the 'restorable' category. The paper's own RQ4 results show much lower demonstrated success (module install 21.5%, FileNotFound synthetic rerun 37%, NameError 45.3%), yielding 5.4% fully and 12.8% partially restored overall. Thus the central claim that only 21.3% of non-executable notebooks are truly pathological is an arithmetic consequence of calling three error types 'restorable' by definition.

full rationale

The paper's headline result is not derived from independent evidence; it is the classification scheme restated. Section IV-A2 defines FileNotFound, ModuleNotFound, and NameError as the fixable categories and 'Others/Non-Fixable' as everything else, so Section V-B's counts follow by construction. The measured restoration outcomes in Section V-D are real, non-circular evidence, but they do not support the 78.7% label: module installation succeeded for 3,760 notebooks, synthetic-data restoration fully or partially restored 1,378 FileNotFound notebooks, and NameError fixes helped 183 notebooks, for an overall 5.4% full and 12.8% partial restoration in the paper's own summary. The conclusion '27,272 can be restored given suitable execution environments' simply repeats the definitional split rather than being derived from restoration success. The paper's other contributions—partial executability of pathological notebooks and improvement percentages from restoration—are independent measurements and are not circular. Score 6 reflects that the central restorability estimate reduces to the taxonomy, while meaningful non-circular measurements remain elsewhere in the paper.

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

The central claim rests on a domain-specific taxonomy (restorable versus pathological error types), a popularity-based dataset definition, and a linear execution model. No new physical or mathematical entities are introduced. The main ledger items are the error-type taxonomy, the star threshold, the sampling fraction, and the execution timeout, all of which influence the headline 21.3% figure.

free parameters (3)
  • Popularity threshold = 4 or more GitHub stars
    Dataset inclusion criterion chosen by the authors to focus on actively reused notebooks; it changes all reported percentages and limits generalization to low-star public notebooks.
  • Notebook sampling fraction = 13%
    Chosen due to LLM compute costs; yields 42,546 notebooks from approximately 318,000. The sample is stratified by star tiers, but the 13% is a hand-chosen budget.
  • Execution timeout = 5 minutes
    Chosen for feasibility. Notebooks requiring long-running training or heavy computation are excluded from the analysis, which affects the measured executability distribution.
assumptions (5)
  • domain assumption GitHub stars measure notebook popularity and reuse
    Used to justify the popularity-filtered dataset; based on references [11] and [12], but not independently validated specifically for notebook reuse.
  • domain assumption Linear top-down execution with Papermill captures notebook executability
    Notebooks are interactive and can be executed in any order; the study assumes sequential execution with first-error halt is a valid executability measure. This is discussed but not formally justified.
  • ad hoc to paper Notebooks failing with ModuleNotFound, FileNotFound, or NameError are restorable and were executable in the author's environment
    Central taxonomy assumption introduced in Section IV-A2. It is not demonstrated per notebook and excludes the possibility that these errors reflect genuine logic bugs.
  • domain assumption LLM-generated synthetic data or function definitions preserve enough semantics for executability
    The paper explicitly separates executability from reproducibility and does not verify semantic correctness of LLM outputs, which is acceptable for the stated goal but limits the strength of restoration claims.
  • domain assumption Python AST def-use analysis correctly identifies undefined names
    The custom AST visitor tracks variable binding, imports, functions, and classes; its correctness is assumed and no evaluation of false positives or false negatives is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Are the Majority of Public Computational Notebooks Pathologically Non-Executable?." pith.science (2026). https://pith.science/paper/7W4APHUA

@misc{pith2026250204184,
  author       = {Pith},
  title        = {Pith review of: Are the Majority of Public Computational Notebooks Pathologically Non-Executable?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7W4APHUA}},
  note         = {Machine review of arXiv:2502.04184}
}
read the original abstract

Computational notebooks are the de facto platforms for exploratory data science, offering an interactive programming environment where users can create, modify, and execute code cells in any sequence. However, this flexibility often introduces code quality issues, with prior studies showing that approximately 76% of public notebooks are non-executable, raising significant concerns about reusability. We argue that the traditional notion of executability - requiring a notebook to run fully and without error - is overly rigid, misclassifying many notebooks and overestimating their non-executability. This paper investigates pathological executability issues in public notebooks under varying notions and degrees of executability. Even partially improving executability can improve code comprehension and offer a pathway for dynamic analyses. With this insight, we first categorize notebooks into potentially restorable and pathological non-executable notebooks and then measure how removing misconfiguration and superficial execution issues in notebooks can improve their executability (i.e., additional cells executed without error). In a dataset of 42,546 popular public notebooks containing 34,659 non-executable notebooks, only 21.3% are truly pathologically non-executable. For restorable notebooks, LLM-based methods fully restore 5.4% of previously non-executable notebooks. Among the partially restored, the executability of notebooks improves by 42.7% and 28% by installing the correct modules and generating synthetic data. These findings challenge prior assumptions, suggesting that notebooks have higher executability than previously reported, many of which offer valuable partial execution, and that their executability should be evaluated within the interactive notebook paradigm rather than through traditional software executability standards.

Figures

Figures reproduced from arXiv: 2502.04184 by the authors.

Figure 1
Figure 1. Notebook [15] is initially non-executable due to an [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. LLM-based error-driven notebook executability analysis and restoration workflow. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Def-use lists for the first two cells in notebook [18]. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Examples of prompts for LLM and responses for different error types. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Distribution of notebooks and their GitHub stars. [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Summary of our investigation results. This shows [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 8
Figure 8. Figure 8: Improvement in executability by addressing Modu [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: Improvement in executability with synthetic input. ≥1000 500-999 300-499 200-299 150-199 125-149 100-124 90-99 80-89 70-79 60-69 55-59 50-54 45-49 40-44 35-39 30-34 25-29 20-24 15-19 10-14 4-9 0 1 2 3 .103 290 1,851 166 91 83 1,709 288 996 893 96 85 67 113 234 98 85 14…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

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

  1. A Methodological Framework for LLM-Based Mining of Software Repositories

    cs.SE 2025-08 conditional novelty 5.0 of 10

    A rapid review and survey of LLM-based repository mining yield a threat-mitigation map and the six-stage PRIMES 2.0 framework for conducting such studies.

Reference graph

Works this paper leans on

55 extracted references · 54 canonical work pages · cited by 1 Pith paper

  1. [1]

    Project jupyter: Computational narratives as the engine of collaborative data science,

    F. Perez and B. E. Granger, “Project jupyter: Computational narratives as the engine of collaborative data science,” Jupyter Blog, 2021

    work page 2021

  2. [2]

    Eliciting best practices for collaboration with computational notebooks,

    L. Quaranta, F. Calefato, and F. Lanubile, “Eliciting best practices for collaboration with computational notebooks,” Proceedings of the ACM on Human-Computer Interaction , vol. 6, 4 2022

    work page 2022

  3. [3]

    A large-scale study about quality and reproducibility of jupyter notebooks,

    J. F. Pimentel, L. Murta, V . Braganholo, and J. Freire, “A large-scale study about quality and reproducibility of jupyter notebooks,” IEEE International Working Conference on Mining Software Repositories , vol. 2019-May, pp. 507–517, 5 2019

    work page 2019

  4. [4]

    To- wards exploring the code reuse from stack overflow during software development,

    Y . Huang, F. Xu, H. Zhou, X. Chen, X. Zhou, and T. Wang, “To- wards exploring the code reuse from stack overflow during software development,” in Proceedings of the 30th IEEE/ACM International Conference on Program Comprehension , ICPC ’22, (New York, NY , USA), p. 548–559, Association for Computing Machinery, 2022

    work page 2022

  5. [5]

    Understanding and improving the quality and reproducibility of jupyter notebooks,

    J. F. Pimentel, L. Murta, V . Braganholo, and J. Freire, “Understanding and improving the quality and reproducibility of jupyter notebooks,” Empirical Software Engineering , vol. 26, pp. 1–55, 7 2021

    work page 2021

  6. [6]

    Restoring execution environments of jupyter notebooks,

    J. Wang, L. Li, and A. Zeller, “Restoring execution environments of jupyter notebooks,” Proceedings - International Conference on Software Engineering, pp. 1622–1633, 3 2021

    work page 2021

  7. [7]

    Restoring the executability of jupyter notebooks by automatic upgrade of deprecated apis,

    C. Zhu, R. K. Saha, M. R. Prasad, and S. Khurshid, “Restoring the executability of jupyter notebooks by automatic upgrade of deprecated apis,” Proceedings - 2021 36th IEEE/ACM International Conference on Automated Software Engineering, ASE 2021 , pp. 240–252, 2021

    work page 2021

  8. [8]

    Manag- ing messes in computational notebooks,

    A. Head, F. Hohman, T. Barik, S. M. Drucker, and R. DeLine, “Manag- ing messes in computational notebooks,” Conference on Human Factors in Computing Systems - Proceedings , 5 2019

    work page 2019

Show all 55 references
  1. [9]

    Assessing and restoring repro- ducibility of jupyter notebooks,

    J. Wang, T. Y . Kuo, L. Li, and A. Zeller, “Assessing and restoring repro- ducibility of jupyter notebooks,” Proceedings - 2020 35th IEEE/ACM International Conference on Automated Software Engineering, ASE 2020, vol. 12, pp. 138–149, 9 2020

    2020

  2. [10]

    The lisp implementation for the pdp- 1 computer

    L. P. Deutsch and E. C. Berkeley, “The lisp implementation for the pdp- 1 computer.” https://s3data.computerhistory.org/pdp-1/DEC.pdp 1.1964. 102650371.pdf, 1964

    1964

  3. [11]

    Understanding the factors that impact the popularity of github repositories,

    H. Borges, A. Hora, and M. T. Valente, “Understanding the factors that impact the popularity of github repositories,” in 2016 IEEE International Conference on Software Maintenance and Evolution (ICSME) , pp. 334– 344, 2016

    2016

  4. [12]

    The Fault in Our Stars: An Analysis of GitHub Stars as an Importance Metric for Web Source Code,

    S. Koch, D. Klein, and M. Johns, “The Fault in Our Stars: An Analysis of GitHub Stars as an Importance Metric for Web Source Code,” in Workshop on Measurements, Attacks, and Defenses for the Web (MADWeb) 2024, 2024

    2024

  5. [13]

    Llms for science: Usage for code generation and data analysis,

    M. Nejjar, L. Zacharias, F. Stiehle, and I. Weber, “Llms for science: Usage for code generation and data analysis,” Journal of Software: Evolution and Process , vol. n/a, no. n/a, p. e2723

  6. [14]

    Soen-101: Code generation by emulating software process models using large language model agents,

    F. Lin, D. J. Kim, Tse-Husn, and Chen, “Soen-101: Code generation by emulating software process models using large language model agents,” 2024

    2024

  7. [15]

    https://github.com/girlscript/winter-of-contributing/blob/ main/Datascience With Python/Machine%20Learning/Algorithms/ Random%20Forest%20Algorithm/random forest algorithm.ipynb,

    GirlScript. https://github.com/girlscript/winter-of-contributing/blob/ main/Datascience With Python/Machine%20Learning/Algorithms/ Random%20Forest%20Algorithm/random forest algorithm.ipynb,

  8. [16]

    G. Atienza. https://github.com/gemaatienza/Deep-Learning-Coursera/ blob/master/5.%20Sequence%20Models/Dinosaurus%20Island%20--% 20Character%20level%20language%20model%20final%20-%20v3. ipynb. Accessed: 2024-11-09

    2024

  9. [17]

    Papermill: Parameterize, execute, and analyze note- books,

    M. Seal et al. , “Papermill: Parameterize, execute, and analyze note- books,” 2018. Version 2.4.0

    2018

  10. [18]

    https://github.com/pytopia/Python-2022/blob/main/Python/ 02.%20Object%20Oriented%20Programming/09%20Data%20Types% 20Methods.ipynb

    PyTopia. https://github.com/pytopia/Python-2022/blob/main/Python/ 02.%20Object%20Oriented%20Programming/09%20Data%20Types% 20Methods.ipynb. Accessed: 2024-08-30

    2022

  11. [19]

    The power of concise prompts in large language models,

    S. Ramlochan, “The power of concise prompts in large language models,” 3 2024

    2024

  12. [20]

    Introducing meta llama 3: The most capable openly available llm to date

    Meta, “Introducing meta llama 3: The most capable openly available llm to date.” https://ai.meta.com/blog/meta-llama-3/

  13. [21]

    Llama 2: Open foundation and fine-tuned chat models,

    H. Touvron, L. Martin, K. Stone, P. Albert, A. Almahairi, Y . Babaei, N. Bashlykov, S. Batra, P. Bhargava, S. Bhosale, et al. , “Llama 2: Open foundation and fine-tuned chat models,” arXiv preprint arXiv:2307.09288, 2023

    2023 arXiv

  14. [22]

    https://github.com/JadFatTail/quant struggle/blob/master/µ/ µ.ipynb

    JadFatTail. https://github.com/JadFatTail/quant struggle/blob/master/µ/ µ.ipynb. Accessed: 2024-11-09

    2024

  15. [23]

    https://github.com/jarodHAN/Python-100-Days-master/ blob/master/Day76-90/code/8-pandas%E5%88%86%E7%BB% 84%E8%81%9A%E5%90%88%E6%93%8D%E4%BD%9C.ipynb

    jarodHAN. https://github.com/jarodHAN/Python-100-Days-master/ blob/master/Day76-90/code/8-pandas%E5%88%86%E7%BB% 84%E8%81%9A%E5%90%88%E6%93%8D%E4%BD%9C.ipynb. Accessed: 2024-11-09

    2024

  16. [24]

    https://github.com/Visualize-ML/Book6 First-Course-in-Data-Science/blob/main/Book6 Ch11 Python Codes/ Bk6 Ch11 01.ipynb

    Visualize-ML. https://github.com/Visualize-ML/Book6 First-Course-in-Data-Science/blob/main/Book6 Ch11 Python Codes/ Bk6 Ch11 01.ipynb. Accessed: 2024-11-09

    2024

  17. [25]

    https://www.kaggle.com/

    Kaggle. https://www.kaggle.com/. Accessed: 2024-10-22

    2024

  18. [26]

    T. Sarkar. https://github.com/tirthajyoti/Stats-Maths-with-Python/blob/ master/Set Algebra with Python.ipynb, 2019. Accessed: 2024-08-30

    2019

  19. [27]

    Tpc-ds: The next gen- eration decision support benchmark,

    Transaction Processing Performance Council, “Tpc-ds: The next gen- eration decision support benchmark,” TPC Benchmark DS Standard Specification, April 2008. Version 2.0.1

    2008

  20. [28]

    Long context rag performance of llms,

    Q. Leng, J. Portes, S. Havens, M. Zaharia, and M. Carbin, “Long context rag performance of llms,” Mosaic AI Research , 2024

    2024

  21. [29]

    Dytan: a generic dynamic taint analysis framework,

    J. Clause, W. Li, and A. Orso, “Dytan: a generic dynamic taint analysis framework,” in Proceedings of the 2007 international symposium on Software testing and analysis , pp. 196–206, 2007

    2007

  22. [30]

    Tracing data errors with view-conditioned causality,

    A. Meliou, W. Gatterbauer, S. Nath, and D. Suciu, “Tracing data errors with view-conditioned causality,” in Proceedings of the 2011 ACM SIGMOD International Conference on Management of data , pp. 505– 516, 2011

    2011

  23. [31]

    Are automated debugging techniques actually helping programmers?,

    C. Parnin and A. Orso, “Are automated debugging techniques actually helping programmers?,” in Proceedings of the 2011 international sym- posium on software testing and analysis , pp. 199–209, 2011

    2011

  24. [32]

    A survey of symbolic execution techniques,

    R. Baldoni, E. Coppa, D. C. D’elia, C. Demetrescu, and I. Finocchi, “A survey of symbolic execution techniques,” ACM Computing Surveys (CSUR), vol. 51, no. 3, pp. 1–39, 2018

    2018

  25. [33]

    Exploration and explanation in computational notebooks,

    A. Rule, A. Tabard, and J. D. Hollan, “Exploration and explanation in computational notebooks,” Conference on Human Factors in Computing Systems - Proceedings , vol. 2018-April, 4 2018

    2018

  26. [34]

    distutils — building and installing python modules — python 3.10.15 documentation

    “distutils — building and installing python modules — python 3.10.15 documentation.” https://docs.python.org/3.10/library/distutils.html

  27. [35]

    Building and distributing packages with setuptools - setup- tools 75.3.0.post20241107 documentation

    “Building and distributing packages with setuptools - setup- tools 75.3.0.post20241107 documentation.” https://setuptools.pypa.io/en/ latest/userguide/

  28. [36]

    Jupyter notebooks—a publishing format for reproducible computational workflows,

    T. Kluyver, B. Ragan-Kelley, F. P ´erez, B. Granger, M. Bussonnier, J. Frederic, K. Kelley, J. Hamrick, J. Grout, S. Corlay, P. Ivanov, D. Avila, S. Abdalla, and C. Willing, “Jupyter notebooks—a publishing format for reproducible computational workflows,” Positioning and Power...

    2016

  29. [37]

    What’s wrong with computational notebooks? pain points, needs, and design opportunities,

    S. Chattopadhyay, I. Prasad, A. Z. Henley, A. Sarma, and T. Barik, “What’s wrong with computational notebooks? pain points, needs, and design opportunities,” Conference on Human Factors in Computing Systems - Proceedings , 4 2020

    2020

  30. [38]

    Aiding collaborative reuse of computational notebooks with annotated cell folding,

    A. Rule, I. Drosos, A. Tabard, and J. D. Hollan, “Aiding collaborative reuse of computational notebooks with annotated cell folding,” Proceed- ings of the ACM on Human-Computer Interaction , vol. 2, 11 2018

    2018

  31. [39]

    Evaluating navigation and comparison performance of computational notebooks on desktop and in virtual reality,

    S. In, E. Krokos, K. Whitley, C. North, and Y . Yang, “Evaluating navigation and comparison performance of computational notebooks on desktop and in virtual reality,” pp. 1–15, 5 2024

    2024

  32. [40]

    Computational reproducibility of Jupyter notebooks from biomedical publications,

    S. Samuel and D. Mietchen, “Computational reproducibility of Jupyter notebooks from biomedical publications,” GigaScience, vol. 13, p. giad113, 01 2024

    2024

  33. [41]

    How data scientists use computational notebooks for real-time collaboration,

    A. Y . Wang, A. Mittal, C. Brooks, and S. Oney, “How data scientists use computational notebooks for real-time collaboration,” Proceedings of the ACM on Human-Computer Interaction , vol. 3, 11 2019

    2019

  34. [42]

    Using the jupyter notebook as a tool for open science: An empirical study,

    B. M. Randles, I. V . Pasquetto, M. S. Golshan, and C. L. Borgman, “Using the jupyter notebook as a tool for open science: An empirical study,” Proceedings of the ACM/IEEE Joint Conference on Digital Libraries, 7 2017

    2017

  35. [43]

    Nbsearch: Semantic search and visual exploration of computational notebooks,

    X. Li, Y . Wang, H. Wang, Y . Wang, and J. Zhao, “Nbsearch: Semantic search and visual exploration of computational notebooks,” Conference on Human Factors in Computing Systems - Proceedings , 5 2021

    2021

  36. [44]

    Outlinespark: Igniting ai-powered presentation slides creation from computational notebooks through outlines,

    F. Wang, Y . Lin, L. Yang, H. Li, M. Gu, M. Zhu, and H. Qu, “Outlinespark: Igniting ai-powered presentation slides creation from computational notebooks through outlines,” pp. 1–16, 5 2024

    2024

  37. [45]

    On the design of ai-powered code assistants for notebooks,

    A. M. McNutt, C. Wang, R. A. Deline, and S. M. Drucker, “On the design of ai-powered code assistants for notebooks,” Conference on Human Factors in Computing Systems - Proceedings , 4 2023

    2023

  38. [46]

    Better code, better sharing:on the need of analyzing jupyter notebooks,

    J. Wang, L. Li, and A. Zeller, “Better code, better sharing:on the need of analyzing jupyter notebooks,” Proceedings - 2020 ACM/IEEE 42nd International Conference on Software Engineering: New Ideas and Emerging Results, ICSE-NIER 2020 , pp. 53–56, 6 2019

    2020

  39. [47]

    Fork it: Supporting stateful alternatives in computational notebooks,

    N. Weinman, T. Barik, and S. M. Drucker, “Fork it: Supporting stateful alternatives in computational notebooks,” Conference on Human Factors in Computing Systems - Proceedings , 5 2021

    2021

  40. [48]

    Demonstration of elasticnotebook: Migrating live computational notebook states,

    Z. Li, S. Chockchowwat, H. Fang, R. Sahu, S. Thakurdesai, K. Pridapha- trakun, and Y . Park, “Demonstration of elasticnotebook: Migrating live computational notebook states,” in Companion of the 2024 International Conference on Management of Data , SIGMOD/PODS ’24, (New York, ...

    2024

  41. [49]

    Facilitating mixed-methods analysis with computational notebooks,

    J. S. Zhu, Z. Zhang, and J. Zhao, “Facilitating mixed-methods analysis with computational notebooks,” 2024

    2024

  42. [50]

    ”don’t step on my toes

    A. Y . Wang, Z. Wu, C. Brooks, and S. Oney, “”don’t step on my toes”: Resolving editing conflicts in real-time collaboration in computational notebooks,” 2024 First IDE Workshop (IDE ’24), April 20, 2024, Lisbon, Portugal, vol. 1, 4 2024

    2024

  43. [51]

    Supernova: Design strategies and opportunities for interactive visualization in computational notebooks,

    Z. J. Wang, D. Munechika, S. Lee, and D. H. Chau, “Supernova: Design strategies and opportunities for interactive visualization in computational notebooks,” in Extended Abstracts of the CHI Conference on Human Factors in Computing Systems , CHI EA ’24, (New York, NY , USA), As...

    2024

  44. [52]

    Error iden- tification strategies for python jupyter notebooks,

    D. Robinson, N. A. Ernst, E. L. Vargas, and M. A. D. Storey, “Error iden- tification strategies for python jupyter notebooks,” IEEE International Conference on Program Comprehension, vol. 2022-March, pp. 253–263, 2022

    2022

  45. [53]

    From computational to conversational note- books,

    T. Weber and S. Mayer, “From computational to conversational note- books,” in Proceedings of the 1st CHI Workshop on Human-Notebook Interactions (Honolulu, Hawaii, USA, 2024-05-11). Online , 2024

    2024

  46. [54]

    Untangling knots: Leveraging llm for error resolution in computational notebooks,

    K. Grotov, S. Titov, Y . Zharov, and T. Bryksin, “Untangling knots: Leveraging llm for error resolution in computational notebooks,” 2024

    2024

  47. [2021]

    Accessed: 2024-08-30

    2024

Pith tools

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