Reproducible Linear Algebra Workflows with Notebooks and Documentation: How Matrix Analysis Becomes Reviewable and Trustworthy

Last Updated July 6, 2026

Reproducible linear algebra workflows with notebooks and documentation explain how matrix-based analysis can be rerun, reviewed, validated, extended, and trusted. In systems modeling, reproducibility is not only about saving code. It is about preserving the full chain from mathematical question to matrix construction, computation, diagnostics, interpretation, figures, outputs, metadata, and governance review.

This article closes Part VIII of the Linear Algebra for Systems Modeling series by connecting notebooks, scripts, documentation, data provenance, environment files, package versions, random seeds, matrix schemas, validation checks, unit tests, diagnostic reports, generated outputs, version control, workflow automation, reproducible figures, computational narratives, audit trails, and responsible interpretation.

The central modeling question is not only “Can this notebook run once?” It is “Can another person understand, rerun, inspect, test, verify, and responsibly interpret the linear algebra workflow after the original analysis is complete?”

Linear algebra workflows often begin in exploration. A notebook is opened. A matrix is loaded. A solver is called. A figure is generated. A result is interpreted. But exploration is not the same as reproducibility. A notebook that runs only on one machine, depends on hidden data, omits package versions, overwrites outputs, lacks tests, and leaves assumptions undocumented is not a durable scientific workflow.

Reproducibility turns matrix analysis into a reviewable object. It makes clear how data became matrices, how operations were chosen, which diagnostics were computed, which outputs were generated, which environment was used, which assumptions were made, and what the results can and cannot support.

Why Reproducibility Matters

Reproducibility matters because linear algebra workflows often produce results that are later cited, reused, scaled, challenged, visualized, or built into larger systems. If the workflow cannot be rerun or inspected, the result becomes difficult to trust even when the mathematics is sound.

A matrix result may depend on many hidden choices: data cleaning, column ordering, unit conversion, scaling, missing-value handling, package versions, random seeds, solver tolerances, sparse storage formats, rank thresholds, and plotting decisions. Reproducibility makes those choices visible.

Reproducibility is not bureaucracy. It is how computational work remains useful after the first successful run.

Back to top ↑

Notebooks as Computational Narratives

Notebooks are powerful because they combine prose, code, equations, tables, figures, and interpretation in one place. For linear algebra, this is especially useful: a notebook can introduce the matrix, show its construction, compute diagnostics, visualize structure, explain results, and link output to modeling purpose.

But notebooks can also create reproducibility problems. They may contain hidden state, stale outputs, manual edits, uncontrolled dependencies, large embedded data, or conclusions that no longer match the code. A good notebook is both exploratory and disciplined.

The best notebooks are not isolated artifacts. They sit inside a documented repository with scripts, tests, data dictionaries, environment files, outputs, and review notes.

Back to top ↑

Notebooks, Scripts, and Repositories

Reproducible linear algebra workflows usually need more than a notebook. Notebooks are useful for explanation and exploration. Scripts are useful for automation. Repositories are useful for structure, versioning, collaboration, and review.

A mature workflow often uses notebooks for explanation, scripts for execution, modules for reusable logic, tests for reliability, and documentation for interpretation.

Back to top ↑

Documenting Matrix Construction

Matrix construction is the foundation of reproducible linear algebra. A matrix is not just an array of numbers. It is a representation of a system: rows, columns, values, zeros, units, missingness, scaling, weights, thresholds, and assumptions.

Without matrix construction documentation, reproducibility is only partial. A solver can be rerun, but the meaning of the input may remain unclear.

Back to top ↑

Data Provenance and Metadata

Data provenance records where data came from, when it was accessed, how it was processed, and how it was transformed. Metadata records the structure and meaning of files, fields, matrices, outputs, and workflows.

In linear algebra workflows, provenance and metadata are especially important because small changes in data processing can change matrix rank, conditioning, sparsity, singular values, eigenvalues, least-squares fits, or state trajectories.

Metadata makes linear algebra workflows legible across time, teams, tools, and review contexts.

Back to top ↑

Environment Control and Dependencies

A notebook or script may depend on programming language versions, packages, numerical libraries, BLAS or LAPACK backends, sparse solvers, operating systems, hardware, random seeds, and file paths. If these dependencies are not controlled, reruns may fail or produce different outputs.

Environment control does not guarantee substantive validity, but it is essential for computational reruns and debugging.

Back to top ↑

Randomness, Determinism, and Seeds

Some linear algebra workflows are deterministic. Others use randomness: randomized SVD, sampling, stochastic optimization, train-test splits, Monte Carlo simulation, bootstrap uncertainty, randomized projections, and approximate algorithms.

When randomness is used, reproducibility requires recording seeds, generators, sampling methods, data order, parallel settings, and nondeterministic hardware behavior where relevant.

A reproducible workflow can include randomness, but the randomness must be controlled and disclosed.

Back to top ↑

Validation, Tests, and Reference Cases

Reproducibility and correctness are related but different. A workflow can be reproducible and wrong. Testing checks whether code behaves as expected. Validation checks whether the workflow is meaningful for the system being modeled.

Testing makes code reviewable. Validation makes the computational result meaningful for systems analysis.

Back to top ↑

Diagnostic Outputs and Reports

A reproducible workflow should produce more than final answers. It should produce diagnostic outputs that show whether the computation can be trusted: residuals, condition numbers, singular values, rank estimates, reconstruction errors, convergence histories, runtime metrics, memory summaries, warnings, and validation checks.

Diagnostics should be generated automatically and saved with the workflow. They should not depend on memory or informal notes.

Back to top ↑

Version Control and Audit Trails

Version control records how code, documentation, and workflow artifacts change over time. For reproducible linear algebra, version control is not only a software practice. It is part of the scientific record.

Audit trails should show what changed, why it changed, who changed it, when it changed, and how the change affected outputs. This is especially important when matrix computations support institutional reports, policy analysis, infrastructure planning, model governance, or public-interest research.

Version control cannot make a bad model good, but it can make model development inspectable.

Back to top ↑

Reproducible Figures and Tables

Figures and tables are often the public face of linear algebra workflows. They summarize residuals, trajectories, singular values, feature projections, network structure, uncertainty, model outputs, and performance. If figures and tables are manually copied or edited, reproducibility weakens.

A reproducible workflow generates figures and tables directly from versioned inputs and scripts. It also records the commands used to generate them and saves the underlying data used for plotting.

Reproducible figures and tables preserve the connection between evidence, computation, and interpretation.

Back to top ↑

Workflow Automation and Continuous Review

Automation helps reproducibility by reducing manual steps. A workflow can define commands for data preparation, matrix construction, testing, diagnostics, figures, reports, and cleanup. Continuous review can run tests automatically when code changes.

Automation should make the workflow easier to audit. It should not hide assumptions or make failure states invisible.

Back to top ↑

Documentation Layers

Good documentation works at multiple levels. A README explains how to run the workflow. A data dictionary explains input meaning. Code comments clarify local logic. Mathematical notes explain formulas and assumptions. A report summarizes diagnostics and interpretation boundaries.

Documentation should help someone else understand not only what the workflow does, but why it was designed that way.

Back to top ↑

Responsible Reproducibility

Reproducibility is necessary but not sufficient. A reproducible workflow can reproduce a biased dataset, a poor model, a misleading visualization, an invalid assumption, or an inappropriate interpretation. Responsible reproducibility pairs rerunnable computation with validation, uncertainty disclosure, domain review, and interpretation boundaries.

Responsible reproducibility preserves the workflow and explains the limits of what that workflow can support.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer. Reproducible linear algebra workflows connect mathematical representation, matrix construction, numerical diagnostics, environment control, execution order, deterministic and randomized algorithms, validation, documentation, provenance, generated outputs, and governance review.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for reproducible linear algebra should document matrix source, row meaning, column meaning, value meaning, units, scaling, preprocessing, missingness, storage format, data type, solver, tolerance, rank threshold, random seed, package versions, numerical backend, runtime environment, commands, generated outputs, diagnostic artifacts, tests, validation results, and interpretation warnings.

The companion repository treats reproducibility as a first-class scientific-computing layer. Python, R, Julia, SQL, Haskell, C, C++, Fortran, Rust, Go, notebooks, schemas, generated outputs, Canvas artifacts, advanced reports, and calculators each support a different layer of workflow design, documentation, validation, metadata, and responsible interpretation.

For this article, the computational examples focus on generating a reproducibility audit, documenting notebook status, environment metadata, matrix construction, residual diagnostics, output manifests, validation checks, and governance notes.

Back to top ↑

Python Workflow: Reproducibility Audit

The Python workflow below creates a compact reproducibility audit for a linear algebra notebook and documentation workflow. It records matrix metadata, execution status, dependency notes, validation checks, residual diagnostics, generated artifacts, and interpretation warnings.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
import math
import platform
import sys


@dataclass(frozen=True)
class ReproducibleLinearAlgebraAudit:
    workflow_name: str
    notebook_status: str
    documentation_status: str
    matrix_shape: str
    matrix_meaning: str
    data_provenance_status: str
    environment_status: str
    random_seed_status: str
    validation_status: str
    generated_outputs_status: str
    residual_norm: float
    relative_residual: float
    reproducibility_score: int
    python_version: str
    platform_summary: str
    interpretation_warning: str


def matvec(A: list[list[float]], x: list[float]) -> list[float]:
    return [sum(row[j] * x[j] for j in range(len(x))) for row in A]


def norm2(x: list[float]) -> float:
    return math.sqrt(sum(value * value for value in x))


def solve2(A: list[list[float]], b: list[float]) -> list[float]:
    determinant = A[0][0] * A[1][1] - A[0][1] * A[1][0]
    if abs(determinant) < 1e-12:
        raise ValueError("Reference matrix is singular or too close to singular.")

    return [
        (b[0] * A[1][1] - A[0][1] * b[1]) / determinant,
        (A[0][0] * b[1] - b[0] * A[1][0]) / determinant,
    ]


def build_audit() -> ReproducibleLinearAlgebraAudit:
    A = [
        [3.0, 1.0],
        [1.0, 2.0],
    ]
    b = [5.0, 5.0]
    solution = solve2(A, b)
    residual = [bi - ai for bi, ai in zip(b, matvec(A, solution))]
    residual_norm = norm2(residual)
    relative_residual = residual_norm / max(norm2(b), 1e-15)

    checklist = {
        "notebook_clean_run": True,
        "readme_present": True,
        "data_dictionary_present": True,
        "environment_recorded": True,
        "random_seed_recorded_or_not_applicable": True,
        "validation_case_present": True,
        "diagnostic_outputs_saved": True,
        "interpretation_warning_present": True,
    }

    reproducibility_score = int(100 * sum(checklist.values()) / len(checklist))

    return ReproducibleLinearAlgebraAudit(
        workflow_name="reproducible_linear_algebra_workflow_audit",
        notebook_status="clean_execution_required_and_documented",
        documentation_status="readme_data_dictionary_method_notes_and_governance_report_required",
        matrix_shape="2x2",
        matrix_meaning="synthetic_reference_system_for_reproducibility_validation",
        data_provenance_status="synthetic_data_documented_in_workflow",
        environment_status="runtime_metadata_recorded",
        random_seed_status="not_applicable_for_deterministic_reference_case",
        validation_status="reference_solution_and_residual_check_passed",
        generated_outputs_status="tables_json_and_reports_written_by_workflow",
        residual_norm=round(residual_norm, 12),
        relative_residual=round(relative_residual, 12),
        reproducibility_score=reproducibility_score,
        python_version=sys.version.split()[0],
        platform_summary=platform.platform(),
        interpretation_warning=(
            "Reproducibility means the workflow can be rerun and reviewed, not that the model is automatically valid. "
            "Matrix construction, diagnostics, assumptions, uncertainty, and domain validation still require review."
        ),
    )


def write_outputs(output_dir: Path) -> None:
    (output_dir / "tables").mkdir(parents=True, exist_ok=True)
    (output_dir / "json").mkdir(parents=True, exist_ok=True)
    (output_dir / "reports").mkdir(parents=True, exist_ok=True)

    audit = build_audit()
    row = asdict(audit)

    with (output_dir / "tables" / "reproducible_linear_algebra_audit.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=list(row.keys()))
        writer.writeheader()
        writer.writerow(row)

    (output_dir / "json" / "reproducible_linear_algebra_audit.json").write_text(
        json.dumps(row, indent=2, sort_keys=True),
        encoding="utf-8",
    )

    report = [
        "# Reproducible Linear Algebra Workflow Audit",
        "",
        f"- Workflow: {audit.workflow_name}",
        f"- Notebook status: {audit.notebook_status}",
        f"- Documentation status: {audit.documentation_status}",
        f"- Validation status: {audit.validation_status}",
        f"- Reproducibility score: {audit.reproducibility_score}",
        f"- Residual norm: {audit.residual_norm}",
        "",
        audit.interpretation_warning,
    ]
    (output_dir / "reports" / "reproducibility_audit_report.md").write_text(
        "\\n".join(report) + "\\n",
        encoding="utf-8",
    )


if __name__ == "__main__":
    write_outputs(Path("outputs"))
    print("Reproducible linear algebra workflow audit complete.")

This workflow treats reproducibility as an auditable object rather than an informal promise.

Back to top ↑

R Workflow: Notebook and Documentation Audit

R can support the same audit by recording matrix metadata, residual checks, reproducibility checklist items, runtime details, and generated outputs.

A <- matrix(
  c(
    3.0, 1.0,
    1.0, 2.0
  ),
  nrow = 2,
  byrow = TRUE
)

b <- c(5.0, 5.0)
solution <- solve(A, b)
residual <- b - A %*% solution
residual_norm <- sqrt(sum(residual^2))
relative_residual <- residual_norm / max(sqrt(sum(b^2)), 1e-15)

checklist <- c(
  notebook_clean_run = TRUE,
  readme_present = TRUE,
  data_dictionary_present = TRUE,
  environment_recorded = TRUE,
  random_seed_recorded_or_not_applicable = TRUE,
  validation_case_present = TRUE,
  diagnostic_outputs_saved = TRUE,
  interpretation_warning_present = TRUE
)

reproducibility_score <- as.integer(100 * sum(checklist) / length(checklist))

audit_record <- data.frame(
  workflow_name = "reproducible_linear_algebra_workflow_audit",
  notebook_status = "clean_execution_required_and_documented",
  documentation_status = "readme_data_dictionary_method_notes_and_governance_report_required",
  matrix_shape = paste(dim(A), collapse = "x"),
  matrix_meaning = "synthetic_reference_system_for_reproducibility_validation",
  data_provenance_status = "synthetic_data_documented_in_workflow",
  environment_status = "runtime_metadata_recorded",
  random_seed_status = "not_applicable_for_deterministic_reference_case",
  validation_status = "reference_solution_and_residual_check_passed",
  generated_outputs_status = "tables_json_and_reports_written_by_workflow",
  residual_norm = residual_norm,
  relative_residual = relative_residual,
  reproducibility_score = reproducibility_score,
  r_version = paste(R.version$major, R.version$minor, sep = "."),
  interpretation_warning = paste(
    "Reproducibility means the workflow can be rerun and reviewed,",
    "not that the model is automatically valid. Matrix construction, diagnostics,",
    "assumptions, uncertainty, and domain validation still require review."
  )
)

dir.create("outputs/tables", recursive = TRUE, showWarnings = FALSE)
write.csv(
  audit_record,
  "outputs/tables/r_reproducible_linear_algebra_audit.csv",
  row.names = FALSE
)

print(audit_record)

This R workflow makes notebook status, documentation status, validation, residuals, and interpretation warnings explicit.

Back to top ↑

Haskell Workflow: Typed Reproducibility Records

Haskell can represent reproducibility requirements as typed records, keeping workflow status, documentation status, validation, residuals, reproducibility score, and interpretation warning attached to the result.

module Main where

data ReproducibleLinearAlgebraAudit = ReproducibleLinearAlgebraAudit
  { workflowName :: String
  , notebookStatus :: String
  , documentationStatus :: String
  , matrixShape :: String
  , matrixMeaning :: String
  , dataProvenanceStatus :: String
  , environmentStatus :: String
  , randomSeedStatus :: String
  , validationStatus :: String
  , generatedOutputsStatus :: String
  , residualNorm :: Double
  , relativeResidual :: Double
  , reproducibilityScore :: Int
  , interpretationWarning :: String
  } deriving (Show)

buildAudit :: ReproducibleLinearAlgebraAudit
buildAudit =
  ReproducibleLinearAlgebraAudit
    "reproducible_linear_algebra_workflow_audit"
    "clean_execution_required_and_documented"
    "readme_data_dictionary_method_notes_and_governance_report_required"
    "2x2"
    "synthetic_reference_system_for_reproducibility_validation"
    "synthetic_data_documented_in_workflow"
    "runtime_metadata_recorded"
    "not_applicable_for_deterministic_reference_case"
    "reference_solution_and_residual_check_passed"
    "tables_json_and_reports_written_by_workflow"
    0.0
    0.0
    100
    "Reproducibility means the workflow can be rerun and reviewed, not that the model is automatically valid. Matrix construction, diagnostics, assumptions, uncertainty, and domain validation still require review."

main :: IO ()
main =
  print buildAudit

The typed record makes reproducibility part of the data model rather than an informal note.

Back to top ↑

SQL Workflow: Reproducibility Governance Registry

SQL can document reproducibility assumptions when notebooks, scripts, repositories, outputs, and reports support institutional workflows or public-interest systems analysis.

CREATE TABLE reproducible_linear_algebra_governance_registry (
    assumption_key TEXT PRIMARY KEY,
    assumption_name TEXT NOT NULL,
    workflow_role TEXT NOT NULL,
    documentation_role TEXT NOT NULL,
    review_warning TEXT NOT NULL
);

INSERT INTO reproducible_linear_algebra_governance_registry VALUES
(
  'matrix_construction',
  'Matrix construction',
  'Defines how source data become matrices and vectors.',
  'Documents row meaning, column meaning, value meaning, units, zeros, missingness, and transformations.',
  'A notebook is not reproducible if the matrix cannot be reconstructed from documented inputs.'
);

INSERT INTO reproducible_linear_algebra_governance_registry VALUES
(
  'notebook_execution',
  'Notebook execution',
  'Defines whether the notebook can run from a clean state.',
  'Records execution order, required inputs, generated outputs, and stale-output controls.',
  'A notebook that depends on hidden state is not a reliable reproducible artifact.'
);

INSERT INTO reproducible_linear_algebra_governance_registry VALUES
(
  'environment_control',
  'Environment control',
  'Defines language versions, packages, numerical backends, and runtime settings.',
  'Supports reruns across machines and future maintenance.',
  'Environment capture supports computation but does not guarantee model validity.'
);

INSERT INTO reproducible_linear_algebra_governance_registry VALUES
(
  'randomness_control',
  'Randomness control',
  'Defines random seeds, generators, sampling methods, and nondeterminism warnings.',
  'Supports reruns for randomized algorithms, simulations, and sampling workflows.',
  'Randomness must be controlled and disclosed when it affects outputs.'
);

INSERT INTO reproducible_linear_algebra_governance_registry VALUES
(
  'validation_tests',
  'Validation tests',
  'Defines reference cases, residual checks, edge cases, and domain checks.',
  'Shows whether code and model outputs are credible under review.',
  'Reproducibility without validation can reproduce the same error repeatedly.'
);

INSERT INTO reproducible_linear_algebra_governance_registry VALUES
(
  'generated_outputs',
  'Generated outputs',
  'Defines tables, figures, logs, JSON files, reports, and manifests created by the workflow.',
  'Connects results to commands, inputs, code, and metadata.',
  'Manually edited outputs weaken traceability.'
);

INSERT INTO reproducible_linear_algebra_governance_registry VALUES
(
  'version_control',
  'Version control',
  'Defines how code, documentation, assumptions, and outputs change over time.',
  'Supports audit trails, review, rollback, and collaboration.',
  'Version control records change but does not replace interpretation review.'
);

INSERT INTO reproducible_linear_algebra_governance_registry VALUES
(
  'responsible_interpretation',
  'Responsible interpretation',
  'Defines how assumptions, uncertainty, validation status, and model limits are communicated.',
  'Prevents reproducible computation from being mistaken for complete truth.',
  'A reproducible workflow still requires judgment about what the results mean.'
);

SELECT
    assumption_name,
    workflow_role,
    documentation_role,
    review_warning
FROM reproducible_linear_algebra_governance_registry
ORDER BY assumption_key;

This registry keeps reproducibility tied to matrix construction, notebook execution, environment control, randomness, validation, generated outputs, version control, and responsible interpretation.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It supports notebook documentation audits, matrix construction records, environment metadata, residual checks, validation reports, output manifests, governance tables, generated artifacts, advanced mathematical audit reports, and reusable calculator scripts.

Back to top ↑

Interpretive Limits and Responsible Use

Reproducible workflows are powerful because they preserve the path from mathematical question to computational result. They allow others to rerun notebooks, inspect scripts, review matrix construction, check diagnostics, compare outputs, validate assumptions, and extend the analysis.

Their limits are equally important. Reproducibility is not the same as truth. A reproducible workflow can preserve a flawed assumption, biased data source, inappropriate model, misleading figure, weak validation strategy, or overconfident interpretation. A notebook can run cleanly and still answer the wrong question. A repository can be well organized and still contain poor modeling judgment.

Responsible use requires pairing reproducibility with validation, uncertainty disclosure, domain knowledge, numerical diagnostics, sensitivity analysis, provenance review, documentation maintenance, and interpretation boundaries. The goal is not merely to make computation repeatable. The goal is to make matrix-based systems analysis inspectable, accountable, and honest about what its evidence can support.

Back to top ↑

Related Articles

• What Is Linear Algebra for Systems Modeling?
• Scientific Computing Workflows for Linear Algebra
• Decomposition Workflows for Systems Analysis
• Numerical Stability and Conditioning
• Visualization of Vectors, Transformations, and State Spaces
• Matrix Operations Across Modeling Languages
• Large-Scale Matrix Computation
• Sparse Matrices and Computational Efficiency
• Simulation of High-Dimensional Systems
• Singular Value Decomposition
• Principal Component Analysis
• Dimensionality Reduction Techniques
• Machine Learning and Linear Algebra
• Representation Choices and Model Assumptions
• Linear Algebra for Systems Modeling
• Scientific Computing for Systems Modeling
• Systems Modeling

Back to top ↑

Further Reading

• Barba, L.A. (2019) ‘Praxis of reproducible computational science’, Computing in Science & Engineering, 21(1), pp. 73–78. Available at: https://doi.org/10.1109/MCSE.2018.2881905.
• Gentleman, R. and Temple Lang, D. (2007) ‘Statistical analyses and reproducible research’, Journal of Computational and Graphical Statistics, 16(1), pp. 1–23. Available at: https://doi.org/10.1198/106186007X178663.
• Jupyter Project (n.d.) Project Jupyter Documentation. Available at: https://docs.jupyter.org/.
• Kluyver, T. et al. (2016) ‘Jupyter Notebooks – a publishing format for reproducible computational workflows’, in Loizides, F. and Schmidt, B. (eds.) Positioning and Power in Academic Publishing: Players, Agents and Agendas. Amsterdam: IOS Press, pp. 87–90. Available at: https://doi.org/10.3233/978-1-61499-649-1-87.
• Peng, R.D. (2011) ‘Reproducible research in computational science’, Science, 334(6060), pp. 1226–1227. Available at: https://doi.org/10.1126/science.1213847.
• Sandve, G.K. et al. (2013) ‘Ten simple rules for reproducible computational research’, PLOS Computational Biology, 9(10), e1003285. Available at: https://doi.org/10.1371/journal.pcbi.1003285.
• Stodden, V., Leisch, F. and Peng, R.D. (eds.) (2014) Implementing Reproducible Research. Boca Raton, FL: CRC Press. Available at: https://doi.org/10.1201/b16868.
• The Turing Way Community (2022) The Turing Way: A Handbook for Reproducible, Ethical and Collaborative Research. Available at: https://the-turing-way.netlify.app/.
• Wilson, G. et al. (2017) ‘Good enough practices in scientific computing’, PLOS Computational Biology, 13(6), e1005510. Available at: https://doi.org/10.1371/journal.pcbi.1005510.
• Wilkinson, M.D. et al. (2016) ‘The FAIR Guiding Principles for scientific data management and stewardship’, Scientific Data, 3, 160018. Available at: https://doi.org/10.1038/sdata.2016.18.

Back to top ↑

References

• Barba, L.A. (2019) ‘Praxis of reproducible computational science’, Computing in Science & Engineering, 21(1), pp. 73–78. Available at: https://doi.org/10.1109/MCSE.2018.2881905.
• Gentleman, R. and Temple Lang, D. (2007) ‘Statistical analyses and reproducible research’, Journal of Computational and Graphical Statistics, 16(1), pp. 1–23. Available at: https://doi.org/10.1198/106186007X178663.
• Jupyter Project (n.d.) Project Jupyter Documentation. Available at: https://docs.jupyter.org/.
• Kluyver, T. et al. (2016) ‘Jupyter Notebooks – a publishing format for reproducible computational workflows’, in Loizides, F. and Schmidt, B. (eds.) Positioning and Power in Academic Publishing: Players, Agents and Agendas. Amsterdam: IOS Press, pp. 87–90. Available at: https://doi.org/10.3233/978-1-61499-649-1-87.
• Peng, R.D. (2011) ‘Reproducible research in computational science’, Science, 334(6060), pp. 1226–1227. Available at: https://doi.org/10.1126/science.1213847.
• Sandve, G.K. et al. (2013) ‘Ten simple rules for reproducible computational research’, PLOS Computational Biology, 9(10), e1003285. Available at: https://doi.org/10.1371/journal.pcbi.1003285.
• Stodden, V., Leisch, F. and Peng, R.D. (eds.) (2014) Implementing Reproducible Research. Boca Raton, FL: CRC Press. Available at: https://doi.org/10.1201/b16868.
• The Turing Way Community (2022) The Turing Way: A Handbook for Reproducible, Ethical and Collaborative Research. Available at: https://the-turing-way.netlify.app/.
• Wilson, G. et al. (2017) ‘Good enough practices in scientific computing’, PLOS Computational Biology, 13(6), e1005510. Available at: https://doi.org/10.1371/journal.pcbi.1005510.
• Wilkinson, M.D. et al. (2016) ‘The FAIR Guiding Principles for scientific data management and stewardship’, Scientific Data, 3, 160018. Available at: https://doi.org/10.1038/sdata.2016.18.

Back to top ↑