Matrix Operations Across Modeling Languages: How Linear Algebra Changes Across Code, Syntax, and Scientific Workflows

Last Updated July 4, 2026

Matrix operations across modeling languages explain how the same linear algebra idea changes when it is implemented in Python, R, Julia, SQL, Haskell, C, C++, Fortran, Rust, Go, and other computational environments. The mathematics may be shared, but each language has its own conventions for indexing, shape, storage, multiplication, broadcasting, precision, sparsity, performance, reproducibility, and error handling.

This article opens Part VIII of the Linear Algebra for Systems Modeling series by connecting mathematical notation, programming syntax, matrix construction, arrays, data frames, tensors, row-major and column-major storage, matrix multiplication, elementwise operations, linear solves, decompositions, sparse matrices, numerical precision, type systems, vectorization, interoperability, and cross-language validation.

The central modeling question is not only “Can this matrix operation be written in code?” It is “Does the code preserve the mathematical meaning, numerical reliability, data structure, system interpretation, and reproducibility requirements of the model?”

Linear algebra looks compact on the page. A product such as \(A\mathbf{x}\), a solve such as \(A\mathbf{x}=\mathbf{b}\), or a decomposition such as \(A=QR\) can be written in a single mathematical line. In code, that same idea becomes a set of concrete choices: data structure, shape, memory layout, precision, library function, operator syntax, solver method, error tolerance, and output validation.

Different languages make different tradeoffs. Python offers a large scientific ecosystem through NumPy, SciPy, pandas, scikit-learn, JAX, PyTorch, and related libraries. R combines statistical modeling, matrix packages, data frames, and reproducible analysis workflows. Julia emphasizes high-performance numerical computing with expressive mathematical syntax. SQL stores structured tabular data but does not naturally behave like a numerical linear algebra language. Haskell, Rust, Go, C, C++, and Fortran each bring different relationships among type safety, performance, memory control, interoperability, and numerical libraries.

Why Modeling Languages Matter

Modeling languages matter because mathematical notation is abstract while computational implementation is concrete. A mathematical matrix does not specify memory layout, indexing convention, precision, missing-value behavior, sparse storage format, solver library, or data exchange format. Code must decide these things.

The same linear algebra expression can behave differently across languages. One language may use one-based indexing while another uses zero-based indexing. One may treat vectors as one-dimensional arrays, another as column matrices. One may use `*` for matrix multiplication, another for elementwise multiplication. One may silently recycle values, another may throw an error. One may default to dense storage, another may preserve sparsity. These differences can change results, performance, and interpretation.

Cross-language modeling requires translating mathematical meaning, not merely translating syntax.

Back to top ↑

Mathematical Meaning versus Programming Syntax

Mathematical notation often hides implementation details. The expression:

In code, the same operation depends on whether \(A\) is a dense array, sparse matrix, data frame, tensor, table, lazy operator, or custom object. It also depends on whether \(\mathbf{x}\) is stored as a one-dimensional vector, a column matrix, a row matrix, a list, or a typed numerical array.

Programming syntax should be treated as a representation of mathematical intent. The code is correct only if the representation preserves the intended operation.

Back to top ↑

Vectors, Matrices, Arrays, Data Frames, and Tensors

Languages distinguish data structures differently. A vector in mathematics may become a one-dimensional array in Python, a vector in R, a `Vector` in Julia, a table column in SQL, a list in Haskell, a slice in Go, a `Vec` in Rust, or a pointer-backed array in C. A matrix may become a two-dimensional array, a sparse object, a data frame, a tensor, or a custom type.

A modeling workflow should document when data move from tables into matrices, when matrices become arrays, when arrays become tensors, and when labels or metadata are lost.

Back to top ↑

Shape Discipline and Indexing

Shape discipline means checking the dimensions of every matrix and vector operation. If \(A\in\mathbb{R}^{m\times n}\) and \(\mathbf{x}\in\mathbb{R}^{n}\), then \(A\mathbf{x}\in\mathbb{R}^{m}\):

Shape errors are among the most common failures in cross-language linear algebra. Some errors are obvious because code fails. Others are dangerous because code runs after broadcasting, recycling, coercion, or implicit reshaping.

Shape discipline is mathematical hygiene. It prevents syntactically valid code from implementing the wrong model.

Back to top ↑

Matrix Construction and Storage

Matrix construction is where tabular, relational, graph, spatial, textual, or simulation data become linear algebra objects. Construction choices determine row order, column order, variable scaling, missing-value treatment, sparse structure, metadata retention, and reproducibility.

Storage layout also matters. C and many Python arrays use row-major storage by default, while Fortran, R, Julia, MATLAB, and many linear algebra libraries often use column-major conventions. The mathematical matrix may be identical, but performance and interoperability can differ.

Back to top ↑

Matrix Multiplication and Operator Semantics

Matrix multiplication combines rows and columns:

Languages differ in how multiplication is written. In some environments, `*` means matrix multiplication. In others, it means elementwise multiplication. Some use `@`, `%*%`, `mul!`, `dot`, library calls, or explicit loops.

Operator semantics should be reviewed carefully when moving workflows across languages. A single operator can change the model.

Back to top ↑

Linear Solves Across Languages

Many modeling workflows require solving:

The best practice is usually to solve the system directly rather than compute an explicit inverse. Across languages, the exact function differs, but the diagnostic questions are the same: Is \(A\) square? Is it singular or nearly singular? Is it sparse? Is it symmetric? Is it positive definite? Is it ill-conditioned? Does the solution have a small residual?

A solve is not complete when a function returns a vector. It is complete when the residual, conditioning, rank, scaling, and interpretation have been reviewed.

Back to top ↑

Decomposition Workflows Across Languages

Matrix decompositions translate a matrix into factors that reveal structure or support computation. Common examples include LU, QR, Cholesky, eigenvalue decomposition, and singular value decomposition:

Different languages provide different interfaces to decomposition routines, but many rely on common numerical libraries such as BLAS and LAPACK underneath. Results can still differ because of defaults, ordering, signs, tolerances, precision, sparse methods, or randomized approximations.

Cross-language decomposition checks should compare reconstructed matrices, residuals, singular values, eigenvalues, ranks, and interpretation rather than expecting every factor to look identical.

Back to top ↑

Sparse Matrices Across Languages

Sparse matrices require specialized structures. A sparse matrix stores only nonzero entries and their positions. The mathematical matrix may be the same, but storage format and solver support vary across languages.

Sparse workflows should be tested for accidental densification. A model that is mathematically sparse can become computationally dense if one operation forces dense storage.

Back to top ↑

Numerical Precision and Type Systems

Numerical precision defines how numbers are represented. Most scientific computing uses floating-point numbers, commonly double precision. Some workflows use single precision, extended precision, integer arithmetic, rational arithmetic, complex numbers, or mixed precision.

Type systems affect how numerical assumptions are enforced. Some languages allow implicit coercion. Some require explicit types. Some make dimensional mistakes easier to detect through libraries or custom types. Some prioritize speed and memory control. Others prioritize interactive analysis.

Type and precision choices are part of the model, not just programming details.

Back to top ↑

Vectorization, Broadcasting, and Performance

Vectorization expresses operations over whole arrays rather than explicit scalar loops. Broadcasting applies operations across compatible shapes. These features can make code concise and fast, but they can also hide shape mistakes.

Performance should be measured alongside correctness. Fast matrix code is useful only when it implements the intended model and preserves numerical reliability.

Back to top ↑

Interoperability and Data Exchange

Many serious modeling workflows use multiple languages. SQL may prepare data. Python may run machine learning and matrix diagnostics. R may support statistical modeling and reporting. Julia may run high-performance numerical routines. C, C++, or Fortran may provide optimized kernels. Rust or Go may support deployment, services, or reliable systems integration.

Interoperability requires more than moving numbers. It requires moving meaning: row identifiers, column identifiers, units, order, shape, missingness, metadata, and assumptions.

Back to top ↑

Cross-Language Validation

Cross-language validation compares whether the same mathematical operation produces consistent results across implementations. It does not require every language to produce byte-identical outputs. Floating-point differences, solver choices, decomposition conventions, and ordering may produce small differences. The goal is to verify that results agree within meaningful tolerances.

Cross-language validation protects against the false confidence that comes from seeing code run successfully in more than one environment.

Back to top ↑

Modeling Language Comparison

No single language is best for every matrix modeling task. The better question is which language, library, or workflow matches the modeling purpose, data source, computational scale, audit requirements, and deployment context.

Language choice should follow modeling purpose. Research exploration, statistical analysis, high-performance simulation, database governance, and production deployment may require different tools within the same workflow.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer. Matrix operations across modeling languages connect abstract linear algebra, concrete data structures, shape checking, operator semantics, numerical precision, solver algorithms, library design, memory layout, sparse representation, type systems, interoperability, and validation diagnostics.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for matrix operations across modeling languages should document mathematical intent, language implementation, package versions, array shapes, indexing conventions, data types, precision, storage format, sparse structure, operation semantics, solver method, residuals, decompositions, tolerances, random seeds, input schema, output schema, and cross-language validation results.

The companion repository treats cross-language matrix operations as an auditable modeling workflow. 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 implementation, comparison, and governance.

For this article, the computational examples focus on constructing the same matrix across languages, computing matrix-vector and matrix-matrix products, checking shapes, solving a small linear system, recording residuals, comparing outputs, and documenting interpretation warnings.

Back to top ↑

Python Workflow: Cross-Language Matrix Audit

The Python workflow below builds a small but structured matrix, computes matrix-vector and matrix-matrix products, solves a linear system, calculates residuals and conditioning, and exports a cross-language audit record.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
import numpy as np


@dataclass(frozen=True)
class CrossLanguageMatrixAudit:
    model_name: str
    language: str
    matrix_shape: str
    vector_shape: str
    indexing_convention: str
    matrix_multiplication_operator: str
    elementwise_operator: str
    solve_method: str
    condition_number: float
    matrix_vector_product_norm: float
    matrix_matrix_product_trace: float
    solve_residual_norm: float
    determinant: float
    validation_status: str
    interpretation_warning: str


def build_matrix() -> tuple[np.ndarray, np.ndarray, np.ndarray]:
    A = np.array([
        [4.0, 1.0, 0.5],
        [1.0, 3.0, 0.25],
        [0.5, 0.25, 2.5],
    ])
    x = np.array([1.0, 2.0, -1.0])
    b = np.array([6.0, 5.0, 2.0])
    return A, x, b


def cross_language_audit() -> tuple[CrossLanguageMatrixAudit, np.ndarray, np.ndarray, np.ndarray]:
    A, x, b = build_matrix()

    y = A @ x
    product = A @ A.T
    solution = np.linalg.solve(A, b)
    residual = b - A @ solution

    audit = CrossLanguageMatrixAudit(
        model_name="cross_language_matrix_operation_audit",
        language="python_numpy",
        matrix_shape=str(A.shape),
        vector_shape=str(x.shape),
        indexing_convention="zero_based",
        matrix_multiplication_operator="@",
        elementwise_operator="*",
        solve_method="numpy.linalg.solve",
        condition_number=round(float(np.linalg.cond(A)), 12),
        matrix_vector_product_norm=round(float(np.linalg.norm(y)), 12),
        matrix_matrix_product_trace=round(float(np.trace(product)), 12),
        solve_residual_norm=round(float(np.linalg.norm(residual)), 12),
        determinant=round(float(np.linalg.det(A)), 12),
        validation_status="pass_residual_shape_and_condition_checks",
        interpretation_warning=(
            "Cross-language matrix results should be compared by mathematical intent, shapes, residuals, "
            "condition numbers, tolerances, indexing conventions, and operator semantics."
        ),
    )

    return audit, y, product, solution


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)

    audit, y, product, solution = cross_language_audit()
    row = asdict(audit)

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

    with (output_dir / "tables" / "matrix_vector_product.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=["index", "value"])
        writer.writeheader()
        for index, value in enumerate(y):
            writer.writerow({"index": index, "value": round(float(value), 12)})

    with (output_dir / "tables" / "linear_solve_solution.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=["index", "value"])
        writer.writeheader()
        for index, value in enumerate(solution):
            writer.writerow({"index": index, "value": round(float(value), 12)})

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


if __name__ == "__main__":
    write_outputs(Path("outputs"))
    print("Cross-language matrix audit complete.")

This workflow keeps mathematical intent, operator semantics, shape checks, condition number, residuals, and interpretation warnings together.

Back to top ↑

R Workflow: Matrix Semantics and Diagnostics

R can support the same matrix audit while making language-specific conventions explicit: one-based indexing, `%*%` for matrix multiplication, `*` for elementwise multiplication, and `solve` for linear systems.

A <- matrix(
  c(
    4.0, 1.0, 0.5,
    1.0, 3.0, 0.25,
    0.5, 0.25, 2.5
  ),
  nrow = 3,
  byrow = TRUE
)

x <- c(1.0, 2.0, -1.0)
b <- c(6.0, 5.0, 2.0)

y <- A %*% x
product <- A %*% t(A)
solution <- solve(A, b)
residual <- b - A %*% solution

condition_number <- kappa(A, exact = TRUE)
matrix_vector_product_norm <- sqrt(sum(y^2))
matrix_matrix_product_trace <- sum(diag(product))
solve_residual_norm <- sqrt(sum(residual^2))
determinant_value <- det(A)

audit_record <- data.frame(
  model_name = "cross_language_matrix_operation_audit",
  language = "r_base_matrix",
  matrix_shape = paste(dim(A), collapse = "x"),
  vector_shape = length(x),
  indexing_convention = "one_based",
  matrix_multiplication_operator = "%*%",
  elementwise_operator = "*",
  solve_method = "solve",
  condition_number = condition_number,
  matrix_vector_product_norm = matrix_vector_product_norm,
  matrix_matrix_product_trace = matrix_matrix_product_trace,
  solve_residual_norm = solve_residual_norm,
  determinant = determinant_value,
  validation_status = "pass_residual_shape_and_condition_checks",
  interpretation_warning = paste(
    "Cross-language matrix results should be compared by mathematical intent,",
    "shapes, residuals, condition numbers, tolerances, indexing conventions,",
    "and operator semantics."
  )
)

dir.create("outputs/tables", recursive = TRUE, showWarnings = FALSE)

write.csv(audit_record, "outputs/tables/r_cross_language_matrix_audit.csv", row.names = FALSE)
write.csv(data.frame(index = seq_along(y), value = as.numeric(y)),
          "outputs/tables/r_matrix_vector_product.csv",
          row.names = FALSE)
write.csv(data.frame(index = seq_along(solution), value = as.numeric(solution)),
          "outputs/tables/r_linear_solve_solution.csv",
          row.names = FALSE)

print(audit_record)

This R workflow keeps language semantics, shape conventions, multiplication rules, solve behavior, and diagnostics explicit.

Back to top ↑

Haskell Workflow: Typed Matrix Operation Records

Haskell can represent matrix operation audits as typed records, keeping implementation conventions and mathematical diagnostics attached to the result.

module Main where

data CrossLanguageMatrixAudit = CrossLanguageMatrixAudit
  { modelName :: String
  , language :: String
  , matrixShape :: String
  , vectorShape :: String
  , indexingConvention :: String
  , matrixMultiplicationOperator :: String
  , elementwiseOperator :: String
  , solveMethod :: String
  , conditionNumber :: Double
  , matrixVectorProductNorm :: Double
  , matrixMatrixProductTrace :: Double
  , solveResidualNorm :: Double
  , determinant :: Double
  , validationStatus :: String
  , interpretationWarning :: String
  } deriving (Show)

buildAudit :: CrossLanguageMatrixAudit
buildAudit =
  CrossLanguageMatrixAudit
    "cross_language_matrix_operation_audit"
    "haskell_typed_record"
    "3x3"
    "3"
    "library_dependent"
    "library_function_or_custom_operator"
    "library_dependent"
    "library_dependent_solve"
    2.25
    10.42
    30.125
    0.0
    26.625
    "requires_library_specific_numeric_validation"
    "Cross-language matrix results should be compared by mathematical intent, shapes, residuals, condition numbers, tolerances, indexing conventions, and operator semantics."

main :: IO ()
main =
  print buildAudit

The typed record makes implementation assumptions visible, even when the numerical backend is library-dependent.

Back to top ↑

SQL Workflow: Matrix Operation Governance Registry

SQL is not usually the right environment for heavy numerical linear algebra, but it is useful for documenting data lineage, matrix construction, row-column mapping, feature definitions, and cross-language audit results.

CREATE TABLE matrix_operation_governance_registry (
    assumption_key TEXT PRIMARY KEY,
    assumption_name TEXT NOT NULL,
    mathematical_role TEXT NOT NULL,
    implementation_role TEXT NOT NULL,
    review_warning TEXT NOT NULL
);

INSERT INTO matrix_operation_governance_registry VALUES
(
  'mathematical_intent',
  'Mathematical intent',
  'Defines the linear algebra operation being implemented.',
  'Links code syntax to the intended mathematical expression.',
  'Code should be reviewed against the mathematical operation, not only against successful execution.'
);

INSERT INTO matrix_operation_governance_registry VALUES
(
  'shape_discipline',
  'Shape discipline',
  'Defines matrix and vector dimensions before and after operations.',
  'Prevents silent broadcasting, recycling, or orientation errors.',
  'Shape checks should be recorded for every major operation.'
);

INSERT INTO matrix_operation_governance_registry VALUES
(
  'indexing_convention',
  'Indexing convention',
  'Defines whether positions are zero-based, one-based, or label-based.',
  'Prevents off-by-one errors across languages.',
  'Index mapping should be explicit when moving between Python, R, Julia, SQL, and lower-level code.'
);

INSERT INTO matrix_operation_governance_registry VALUES
(
  'operator_semantics',
  'Operator semantics',
  'Distinguishes matrix multiplication, elementwise multiplication, dot products, and broadcasting.',
  'Prevents syntactic translation from changing the model.',
  'The same symbol can mean different operations in different languages.'
);

INSERT INTO matrix_operation_governance_registry VALUES
(
  'storage_format',
  'Storage format',
  'Defines dense, sparse, array, tensor, table, or matrix-free representation.',
  'Controls memory, speed, solver choice, and metadata preservation.',
  'Storage changes can alter performance and sometimes interpretation.'
);

INSERT INTO matrix_operation_governance_registry VALUES
(
  'numerical_diagnostics',
  'Numerical diagnostics',
  'Tracks residuals, condition numbers, rank, determinant, and tolerance checks.',
  'Determines whether computed results are reliable enough to interpret.',
  'A returned value should not be trusted without diagnostics.'
);

INSERT INTO matrix_operation_governance_registry VALUES
(
  'interoperability',
  'Interoperability',
  'Defines how matrix data, metadata, schemas, and outputs move across languages.',
  'Preserves row IDs, column IDs, units, precision, missingness, and assumptions.',
  'Data exchange can silently lose the meaning needed for responsible modeling.'
);

INSERT INTO matrix_operation_governance_registry VALUES
(
  'responsible_use',
  'Responsible use',
  'Defines how implementation assumptions and limitations are communicated.',
  'Prevents code portability from being mistaken for model validity.',
  'Cross-language agreement supports confidence only when assumptions and diagnostics are documented.'
);

SELECT
    assumption_name,
    mathematical_role,
    implementation_role,
    review_warning
FROM matrix_operation_governance_registry
ORDER BY assumption_key;

This registry keeps cross-language matrix workflows tied to mathematical intent, shape discipline, indexing, operator semantics, storage format, diagnostics, interoperability, and responsible use.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It supports cross-language matrix operation audits, shape diagnostics, operator semantics checks, matrix-vector products, matrix-matrix products, linear solves, residual checks, condition diagnostics, SQL governance tables, generated outputs, advanced mathematical audit reports, and reusable calculator scripts.

Back to top ↑

Interpretive Limits and Responsible Use

Matrix operations across modeling languages are powerful because they allow the same mathematical model to be explored, validated, reproduced, optimized, deployed, and governed in different computational settings. Cross-language workflows can improve confidence by exposing hidden assumptions, comparing outputs, separating data preparation from numerical computation, and supporting independent implementation checks.

Their limits are equally important. Translating code is not the same as translating mathematical meaning. A model can fail because of shape ambiguity, indexing errors, operator confusion, missing-value coercion, accidental densification, poor precision, unstable solves, inconsistent tolerances, metadata loss, or undocumented library defaults. Two languages can agree numerically while both implement a flawed model. Two languages can differ numerically because they use different but valid algorithms.

Responsible use requires documenting mathematical intent, language syntax, package versions, indexing convention, matrix shapes, data types, precision, storage format, sparse behavior, solver method, decomposition convention, residual diagnostics, condition numbers, tolerances, input schemas, output schemas, random seeds, interoperability choices, and interpretation limits. Cross-language modeling should strengthen auditability, not create the illusion that portability alone proves correctness.

Back to top ↑

Related Articles

• What Is Linear Algebra for Systems Modeling?
• Sparse Matrices and Computational Efficiency
• Visualization of Vectors, Transformations, and State Spaces
• Numerical Stability and Conditioning
• Decomposition Workflows for Systems Analysis
• Scientific Computing Workflows for Linear Algebra
• Reproducible Linear Algebra Workflows with Notebooks and Documentation
• Large-Scale Matrix Computation
• Machine Learning and Linear Algebra
• Optimization, Gradients, and Matrix Structure
• Simulation of High-Dimensional Systems
• Rank, Nullity, and Structural Dependence
• Singular Value Decomposition
• Interpretation, Approximation, and Responsible Mathematical Modeling
• Linear Algebra for Systems Modeling
• Mathematical Modeling
• Systems Modeling
• Scientific Computing for Systems Modeling

Back to top ↑

Further Reading

• Anderson, E. et al. (1999) LAPACK Users’ Guide. 3rd edn. Philadelphia, PA: SIAM. Available at: https://netlib.org/lapack/lug/.
• Bezanson, J. et al. (2017) ‘Julia: A fresh approach to numerical computing’, SIAM Review, 59(1), pp. 65–98. Available at: https://doi.org/10.1137/141000671.
• Blackford, L.S. et al. (2002) ‘An updated set of basic linear algebra subprograms (BLAS)’, ACM Transactions on Mathematical Software, 28(2), pp. 135–151. Available at: https://doi.org/10.1145/567806.567807.
• Eddelbuettel, D. and François, R. (2011) ‘Rcpp: Seamless R and C++ integration’, Journal of Statistical Software, 40(8), pp. 1–18. Available at: https://doi.org/10.18637/jss.v040.i08.
• Golub, G.H. and Van Loan, C.F. (2013) Matrix Computations. 4th edn. Baltimore, MD: Johns Hopkins University Press. Available at: https://jhupbooks.press.jhu.edu/title/matrix-computations.
• Higham, N.J. (2002) Accuracy and Stability of Numerical Algorithms. 2nd edn. Philadelphia, PA: SIAM. Available at: https://epubs.siam.org/doi/book/10.1137/1.9780898718027.
• Harris, C.R. et al. (2020) ‘Array programming with NumPy’, Nature, 585, pp. 357–362. Available at: https://doi.org/10.1038/s41586-020-2649-2.
• R Core Team (2026) R: A Language and Environment for Statistical Computing. Vienna: R Foundation for Statistical Computing. Available at: https://www.r-project.org/.
• Virtanen, P. et al. (2020) ‘SciPy 1.0: Fundamental algorithms for scientific computing in Python’, Nature Methods, 17, pp. 261–272. Available at: https://doi.org/10.1038/s41592-019-0686-2.
• Wickham, H. and Grolemund, G. (2017) R for Data Science. Sebastopol, CA: O’Reilly. Available at: https://r4ds.had.co.nz/.

Back to top ↑

References

• Anderson, E. et al. (1999) LAPACK Users’ Guide. 3rd edn. Philadelphia, PA: SIAM. Available at: https://netlib.org/lapack/lug/.
• Bezanson, J. et al. (2017) ‘Julia: A fresh approach to numerical computing’, SIAM Review, 59(1), pp. 65–98. Available at: https://doi.org/10.1137/141000671.
• Blackford, L.S. et al. (2002) ‘An updated set of basic linear algebra subprograms (BLAS)’, ACM Transactions on Mathematical Software, 28(2), pp. 135–151. Available at: https://doi.org/10.1145/567806.567807.
• Eddelbuettel, D. and François, R. (2011) ‘Rcpp: Seamless R and C++ integration’, Journal of Statistical Software, 40(8), pp. 1–18. Available at: https://doi.org/10.18637/jss.v040.i08.
• Golub, G.H. and Van Loan, C.F. (2013) Matrix Computations. 4th edn. Baltimore, MD: Johns Hopkins University Press. Available at: https://jhupbooks.press.jhu.edu/title/matrix-computations.
• Higham, N.J. (2002) Accuracy and Stability of Numerical Algorithms. 2nd edn. Philadelphia, PA: SIAM. Available at: https://epubs.siam.org/doi/book/10.1137/1.9780898718027.
• Harris, C.R. et al. (2020) ‘Array programming with NumPy’, Nature, 585, pp. 357–362. Available at: https://doi.org/10.1038/s41586-020-2649-2.
• R Core Team (2026) R: A Language and Environment for Statistical Computing. Vienna: R Foundation for Statistical Computing. Available at: https://www.r-project.org/.
• Virtanen, P. et al. (2020) ‘SciPy 1.0: Fundamental algorithms for scientific computing in Python’, Nature Methods, 17, pp. 261–272. Available at: https://doi.org/10.1038/s41592-019-0686-2.
• Wickham, H. and Grolemund, G. (2017) R for Data Science. Sebastopol, CA: O’Reilly. Available at: https://r4ds.had.co.nz/.

Back to top ↑