Numerical Stability and Conditioning: How Linear Algebra Diagnoses Fragile Computation and Sensitive Systems

Last Updated July 4, 2026

Numerical stability and conditioning explain why mathematically correct linear algebra can still produce unreliable computational results when systems are sensitive, poorly scaled, nearly singular, or affected by floating-point error. In systems modeling, the issue is not only whether a matrix operation is valid in theory. The issue is whether the computed answer can be trusted under the limits of finite precision, noisy data, approximate algorithms, and uncertain assumptions.

This article continues Part VIII of the Linear Algebra for Systems Modeling series by connecting floating-point arithmetic, roundoff error, truncation error, residuals, forward error, backward error, condition numbers, singular values, matrix norms, ill-conditioning, near singularity, scaling, pivoting, stable algorithms, least squares, eigenvalue sensitivity, sparse solvers, iterative convergence, uncertainty, validation, and responsible interpretation.

The central modeling question is not only “Did the solver return an answer?” It is “How sensitive is the problem, how stable is the algorithm, how large is the numerical error, and whether the result is reliable enough to support interpretation or decision-making?”

Linear algebra often looks exact on paper. A system \(A\mathbf{x}=\mathbf{b}\) has a solution, a matrix has singular values, a least-squares problem has a best approximation, and an eigenvalue problem has modes. Computational linear algebra is different. Numbers are rounded. Data are noisy. Matrices may be nearly singular. Variables may have incompatible scales. Algorithms may amplify small errors. A residual may be small while the solution is still inaccurate.

Numerical stability and conditioning separate three questions that are often confused. Is the mathematical problem sensitive? Is the algorithm stable? Is the computed result accurate enough for the modeling purpose? A responsible workflow must answer all three before treating computed output as evidence.

Why Stability and Conditioning Matter

Stability and conditioning matter because systems models often rely on computed quantities that are not directly observed: solutions, parameters, forecasts, equilibria, sensitivities, projections, modes, rankings, and optimized allocations. If those quantities are numerically unstable or highly sensitive, the model may appear precise while being fragile.

A model can fail numerically even when its mathematics is valid. A matrix can be invertible but nearly singular. A solver can return a vector that satisfies the equation poorly. A least-squares fit can be dominated by correlated columns. An eigenvalue can shift dramatically after a small perturbation. A large simulation can accumulate small errors over many steps.

Numerical reliability is part of model validity. A result that cannot survive perturbation, scaling review, or residual testing should be interpreted cautiously.

Back to top ↑

Floating-Point Arithmetic

Computers usually represent real numbers with floating-point arithmetic. Floating-point numbers approximate real numbers using finite precision. This means many real numbers cannot be represented exactly, and arithmetic operations introduce rounding.

The symbol \(\epsilon\) is often associated with machine precision. In double precision, floating-point arithmetic is usually accurate enough for many scientific tasks, but not all. When problems are ill-conditioned, nearly singular, badly scaled, or extremely iterative, small floating-point errors can matter.

Floating-point arithmetic does not make computation unreliable by default. It means reliability has to be checked rather than assumed.

Back to top ↑

Roundoff, Truncation, and Model Error

Numerical workflows involve different sources of error. Roundoff error comes from finite precision arithmetic. Truncation error comes from approximating a mathematical process with a finite method, such as stopping an iteration or discretizing a continuous system. Model error comes from assumptions that do not match the system.

These errors interact. A poorly conditioned problem can amplify data error. An unstable algorithm can amplify roundoff error. A model with weak assumptions can generate visually precise but substantively misleading outputs.

Back to top ↑

Conditioning as Problem Sensitivity

Conditioning describes the sensitivity of a mathematical problem to small changes in input. It is a property of the problem, not the algorithm. A problem can be well-conditioned or ill-conditioned before any code is written.

For a linear system \(A\mathbf{x}=\mathbf{b}\), conditioning asks how much the solution \(\mathbf{x}\) changes when \(A\) or \(\mathbf{b}\) changes slightly. In systems modeling, those changes may represent measurement noise, uncertainty, data revision, perturbation, rounding, or scenario variation.

Ill-conditioning is not a programming bug. It is a warning about the mathematical structure of the problem.

Back to top ↑

Condition Numbers and Matrix Norms

The condition number of a nonsingular matrix is commonly written as:

Condition numbers depend on the norm used. Common norms include the \(1\)-norm, \(2\)-norm, infinity norm, and Frobenius norm. The \(2\)-norm condition number has an especially important relationship to singular values:

A high condition number does not always make a model useless, but it changes what can be responsibly claimed from the computation.

Back to top ↑

Singular Values and Near Singularity

Singular values reveal how a matrix stretches space along orthogonal directions. If one singular value is very small, the matrix nearly collapses some direction. This makes inverse problems sensitive because information along that direction is weakly represented.

Near singularity often appears in systems with redundant variables, highly correlated features, weak measurements, insufficient data, structural dependence, or constraints that almost duplicate one another.

SVD diagnostics make conditioning visible. They show which directions are trustworthy and which directions are fragile.

Back to top ↑

Residuals, Forward Error, and Backward Error

For a computed solution \(\hat{\mathbf{x}}\) to \(A\mathbf{x}=\mathbf{b}\), the residual is:

A small residual is useful but not sufficient. In an ill-conditioned problem, a small residual can coexist with a large forward error. Forward error measures how close \(\hat{\mathbf{x}}\) is to the true solution. Backward error asks whether \(\hat{\mathbf{x}}\) is the exact solution to a nearby problem.

Residuals should be interpreted together with conditioning, scaling, and modeling purpose. A residual is a diagnostic, not a guarantee.

Back to top ↑

Algorithmic Stability

Algorithmic stability describes whether a computational method controls error growth. A stable algorithm produces results close to the exact answer for a nearby problem. An unstable algorithm may amplify roundoff error unnecessarily.

Conditioning and stability are different. Conditioning belongs to the problem. Stability belongs to the algorithm. A well-conditioned problem can be solved poorly by an unstable algorithm. An ill-conditioned problem can be solved by a stable algorithm but still produce sensitive outputs.

Stable numerical workflows choose algorithms that respect matrix structure, avoid unnecessary inverses, reduce cancellation, use pivoting when needed, and report diagnostics.

Back to top ↑

Scaling, Normalization, and Units

Scaling changes the numerical size of variables. It can improve conditioning and solver behavior, especially when variables have different units or magnitudes. In systems modeling, scaling must be done carefully because it changes the coordinate representation of the problem.

Scaling can improve numerical behavior, but scaling choices must be recorded because they shape interpretation.

Back to top ↑

Pivoting, Factorization, and Solver Choice

Solving linear systems reliably often depends on factorization strategy. LU factorization, QR decomposition, Cholesky factorization, and SVD-based methods have different stability properties and structural requirements.

Solver choice should follow matrix structure and diagnostic needs. Computing an explicit inverse is rarely the best way to solve a system.

Back to top ↑

Least Squares and Normal Equations

Least-squares problems often appear in model fitting, estimation, forecasting, calibration, regression, and inverse problems. The goal is to minimize residual size:

The normal equations are mathematically important:

Computationally, directly forming \(A^TA\) can worsen conditioning because the condition number is squared:

QR and SVD methods are usually preferred for numerically reliable least-squares computation, especially when columns are correlated or nearly dependent.

Back to top ↑

Eigenvalue and SVD Sensitivity

Eigenvalues and eigenvectors can be sensitive to perturbation, especially for nonnormal matrices or matrices with nearly repeated eigenvalues. SVD is often more stable for diagnosing rank and conditioning because singular values behave more predictably in many settings.

Spectral outputs should be interpreted through perturbation tests, scaling review, and model meaning. A computed eigenvalue is not automatically a stable system mode.

Back to top ↑

Sparse and Iterative Solver Stability

Large sparse systems are often solved iteratively. Iterative methods depend on residual reduction, preconditioning, stopping tolerance, matrix structure, and conditioning. A method can converge slowly, stagnate, or appear to converge under a weak diagnostic.

Iterative solver results should include residual history, stopping reason, tolerance, iteration count, preconditioner, and interpretation warning.

Back to top ↑

Stability in Systems Modeling

Stability and conditioning matter across systems modeling because many models are built from imperfect measurements, estimated parameters, scaled variables, sparse structures, and approximations. Numerical fragility can become institutional fragility when computed outputs guide decisions.

Numerical stability is not a narrow technical detail. It shapes what can be responsibly inferred from computational systems models.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer. Numerical stability and conditioning connect floating-point arithmetic, perturbation theory, matrix norms, singular values, residual diagnostics, backward error, stable factorization, least-squares computation, eigenvalue sensitivity, sparse solver convergence, regularization, and validation.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for numerical stability and conditioning should document matrix shape, data type, precision, norm choice, condition number, singular values, determinant when relevant, residual norm, relative residual, solver method, factorization, pivoting, scaling, tolerance, iteration count, stopping reason, perturbation tests, and interpretation warnings.

The companion repository treats stability and conditioning as an auditable scientific-computing 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 diagnostic review and responsible interpretation.

For this article, the computational examples focus on building a well-conditioned and ill-conditioned system, comparing condition numbers, solving both systems, computing residuals, estimating sensitivity under perturbation, exporting diagnostic tables, and documenting stability governance assumptions.

Back to top ↑

Python Workflow: Stability and Conditioning Audit

The Python workflow below compares a well-conditioned system with an ill-conditioned system, computes condition numbers, solves both systems, measures residuals, applies perturbations, and exports stability diagnostics.

from __future__ import annotations

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


@dataclass(frozen=True)
class StabilityConditioningAudit:
    model_name: str
    matrix_case: str
    matrix_shape: str
    determinant: float
    condition_number_proxy: float
    solution_norm: float
    residual_norm: float
    relative_residual: float
    perturbation_size: float
    perturbed_solution_change: float
    stability_status: 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(v * v for v in x))


def det2(A: list[list[float]]) -> float:
    return A[0][0] * A[1][1] - A[0][1] * A[1][0]


def solve2(A: list[list[float]], b: list[float]) -> list[float]:
    determinant = det2(A)
    if abs(determinant) < 1e-14:
        raise ValueError("Matrix is singular or too close to singular for this simple demonstration.")

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


def inverse2(A: list[list[float]]) -> list[list[float]]:
    determinant = det2(A)
    if abs(determinant) < 1e-14:
        raise ValueError("Matrix is singular or nearly singular.")
    return [
        [A[1][1] / determinant, -A[0][1] / determinant],
        [-A[1][0] / determinant, A[0][0] / determinant],
    ]


def frobenius_norm(A: list[list[float]]) -> float:
    return math.sqrt(sum(value * value for row in A for value in row))


def condition_proxy(A: list[list[float]]) -> float:
    return frobenius_norm(A) * frobenius_norm(inverse2(A))


def audit_case(case_name: str, A: list[list[float]], b: list[float]) -> StabilityConditioningAudit:
    x = solve2(A, b)
    residual = [bi - ai for bi, ai in zip(b, matvec(A, x))]
    residual_norm = norm2(residual)
    relative_residual = residual_norm / max(norm2(b), 1e-15)

    perturbation_size = 1e-5
    b_perturbed = [b[0] + perturbation_size, b[1] - perturbation_size]
    x_perturbed = solve2(A, b_perturbed)
    solution_change = norm2([xp - xi for xp, xi in zip(x_perturbed, x)])

    cond = condition_proxy(A)
    status = "review_required_ill_conditioned" if cond > 1_000 else "stable_under_demo_threshold"

    return StabilityConditioningAudit(
        model_name="numerical_stability_conditioning_audit",
        matrix_case=case_name,
        matrix_shape="2x2",
        determinant=round(det2(A), 12),
        condition_number_proxy=round(cond, 12),
        solution_norm=round(norm2(x), 12),
        residual_norm=round(residual_norm, 12),
        relative_residual=round(relative_residual, 12),
        perturbation_size=perturbation_size,
        perturbed_solution_change=round(solution_change, 12),
        stability_status=status,
        interpretation_warning=(
            "Residuals should be interpreted alongside conditioning, scaling, perturbation sensitivity, "
            "solver method, precision, and model purpose."
        ),
    )


def build_audits() -> list[StabilityConditioningAudit]:
    well_conditioned_A = [
        [3.0, 0.5],
        [0.5, 2.0],
    ]
    ill_conditioned_A = [
        [1.0, 0.9999],
        [0.9999, 0.9998],
    ]
    b = [1.0, 0.5]

    return [
        audit_case("well_conditioned_system", well_conditioned_A, b),
        audit_case("ill_conditioned_system", ill_conditioned_A, b),
    ]


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)

    audits = build_audits()
    rows = [asdict(audit) for audit in audits]

    with (output_dir / "tables" / "stability_conditioning_audit.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)

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


if __name__ == "__main__":
    write_outputs(Path("outputs"))
    print("Numerical stability and conditioning audit complete.")

This workflow keeps condition estimates, residuals, perturbation sensitivity, and interpretation warnings together.

Back to top ↑

R Workflow: Conditioning Diagnostics

R can support the same conditioning audit using matrix solves, condition estimates, residuals, perturbation tests, and exported diagnostic tables.

audit_case <- function(case_name, A, b) {
  solution <- solve(A, b)
  residual <- b - A %*% solution

  perturbation_size <- 1e-5
  b_perturbed <- c(b[1] + perturbation_size, b[2] - perturbation_size)
  solution_perturbed <- solve(A, b_perturbed)

  condition_number <- kappa(A, exact = TRUE)
  solution_change <- sqrt(sum((solution_perturbed - solution)^2))

  stability_status <- ifelse(
    condition_number > 1000,
    "review_required_ill_conditioned",
    "stable_under_demo_threshold"
  )

  data.frame(
    model_name = "numerical_stability_conditioning_audit",
    matrix_case = case_name,
    matrix_shape = paste(dim(A), collapse = "x"),
    determinant = det(A),
    condition_number = condition_number,
    solution_norm = sqrt(sum(solution^2)),
    residual_norm = sqrt(sum(residual^2)),
    relative_residual = sqrt(sum(residual^2)) / max(sqrt(sum(b^2)), 1e-15),
    perturbation_size = perturbation_size,
    perturbed_solution_change = solution_change,
    stability_status = stability_status,
    interpretation_warning = paste(
      "Residuals should be interpreted alongside conditioning, scaling,",
      "perturbation sensitivity, solver method, precision, and model purpose."
    )
  )
}

well_conditioned_A <- matrix(
  c(
    3.0, 0.5,
    0.5, 2.0
  ),
  nrow = 2,
  byrow = TRUE
)

ill_conditioned_A <- matrix(
  c(
    1.0, 0.9999,
    0.9999, 0.9998
  ),
  nrow = 2,
  byrow = TRUE
)

b <- c(1.0, 0.5)

audit_record <- rbind(
  audit_case("well_conditioned_system", well_conditioned_A, b),
  audit_case("ill_conditioned_system", ill_conditioned_A, b)
)

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

print(audit_record)

This R workflow makes conditioning and perturbation sensitivity visible rather than reporting only a returned solution.

Back to top ↑

Haskell Workflow: Typed Stability Records

Haskell can represent numerical stability diagnostics as typed records, keeping conditioning, residuals, perturbation sensitivity, and interpretation warnings attached to the computed result.

module Main where

data StabilityConditioningAudit = StabilityConditioningAudit
  { modelName :: String
  , matrixCase :: String
  , matrixShape :: String
  , determinantValue :: Double
  , conditionNumberProxy :: Double
  , solutionNorm :: Double
  , residualNorm :: Double
  , relativeResidual :: Double
  , perturbationSize :: Double
  , perturbedSolutionChange :: Double
  , stabilityStatus :: String
  , interpretationWarning :: String
  } deriving (Show)

wellConditionedAudit :: StabilityConditioningAudit
wellConditionedAudit =
  StabilityConditioningAudit
    "numerical_stability_conditioning_audit"
    "well_conditioned_system"
    "2x2"
    5.75
    2.10
    0.34
    0.0
    0.0
    0.00001
    0.000004
    "stable_under_demo_threshold"
    "Residuals should be interpreted alongside conditioning, scaling, perturbation sensitivity, solver method, precision, and model purpose."

illConditionedAudit :: StabilityConditioningAudit
illConditionedAudit =
  StabilityConditioningAudit
    "numerical_stability_conditioning_audit"
    "ill_conditioned_system"
    "2x2"
    (-0.00000001)
    399920000.0
    50000000.0
    0.0
    0.0
    0.00001
    2000.0
    "review_required_ill_conditioned"
    "Residuals should be interpreted alongside conditioning, scaling, perturbation sensitivity, solver method, precision, and model purpose."

main :: IO ()
main =
  mapM_ print [wellConditionedAudit, illConditionedAudit]

The typed record prevents a numerical result from being separated from the diagnostics needed to interpret it.

Back to top ↑

SQL Workflow: Stability Governance Registry

SQL can document numerical stability assumptions when computational outputs support systems modeling, reporting, dashboards, audits, or decision workflows.

CREATE TABLE numerical_stability_governance_registry (
    assumption_key TEXT PRIMARY KEY,
    assumption_name TEXT NOT NULL,
    mathematical_role TEXT NOT NULL,
    computational_role TEXT NOT NULL,
    review_warning TEXT NOT NULL
);

INSERT INTO numerical_stability_governance_registry VALUES
(
  'floating_point_precision',
  'Floating-point precision',
  'Defines how real numbers are approximated by finite precision arithmetic.',
  'Controls rounding behavior, tolerance needs, and reproducibility.',
  'Computed precision should not be mistaken for real-world certainty.'
);

INSERT INTO numerical_stability_governance_registry VALUES
(
  'conditioning',
  'Conditioning',
  'Measures sensitivity of the mathematical problem to input perturbations.',
  'Determines whether small data changes can strongly alter outputs.',
  'Ill-conditioned outputs require sensitivity testing and cautious interpretation.'
);

INSERT INTO numerical_stability_governance_registry VALUES
(
  'condition_number',
  'Condition number',
  'Quantifies relative sensitivity using a matrix norm and inverse behavior.',
  'Provides a diagnostic for numerical fragility.',
  'High condition numbers can make small residuals misleading.'
);

INSERT INTO numerical_stability_governance_registry VALUES
(
  'residual_norm',
  'Residual norm',
  'Measures how well a computed solution satisfies the original equation.',
  'Checks solver output against the modeled system.',
  'A small residual alone does not guarantee small forward error.'
);

INSERT INTO numerical_stability_governance_registry VALUES
(
  'solver_choice',
  'Solver choice',
  'Defines the algorithm used to solve, factor, approximate, or iterate.',
  'Shapes numerical stability, runtime, and diagnostic behavior.',
  'Solver choice should match matrix structure, conditioning, sparsity, and accuracy needs.'
);

INSERT INTO numerical_stability_governance_registry VALUES
(
  'scaling',
  'Scaling',
  'Defines row, column, variable, unit, or feature transformations.',
  'Can improve numerical behavior while changing interpretive coordinates.',
  'Scaling choices should be recorded and interpreted in relation to original units.'
);

INSERT INTO numerical_stability_governance_registry VALUES
(
  'perturbation_testing',
  'Perturbation testing',
  'Tests output sensitivity under small input or coefficient changes.',
  'Connects numerical sensitivity to modeling uncertainty.',
  'Outputs that shift dramatically under small perturbations should not be overinterpreted.'
);

INSERT INTO numerical_stability_governance_registry VALUES
(
  'responsible_use',
  'Responsible use',
  'Defines how numerical limits, uncertainty, diagnostics, and model assumptions are communicated.',
  'Prevents computed output from being treated as stronger evidence than it is.',
  'Numerical diagnostics should accompany consequential model results.'
);

SELECT
    assumption_name,
    mathematical_role,
    computational_role,
    review_warning
FROM numerical_stability_governance_registry
ORDER BY assumption_key;

This registry keeps numerical workflows tied to floating-point precision, conditioning, condition numbers, residuals, solver choice, scaling, perturbation testing, and responsible use.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It supports numerical stability audits, conditioning diagnostics, residual checks, perturbation tests, scaling review, solver governance tables, generated outputs, advanced mathematical audit reports, and reusable calculator scripts.

Back to top ↑

Interpretive Limits and Responsible Use

Numerical stability and conditioning are powerful because they help distinguish reliable computation from fragile output. They show when a matrix problem is sensitive, when an algorithm is stable, when a residual is meaningful, when scaling matters, when singular values reveal near-dependence, and when perturbation tests are necessary before interpretation.

Their limits are equally important. A condition number is a diagnostic, not a complete theory of uncertainty. A small residual is not proof of a correct solution. A stable algorithm cannot remove sensitivity from an ill-conditioned problem. A better-scaled system can still be a poor model. A visually precise result can still be dominated by measurement error, preprocessing choices, or structural assumptions.

Responsible use requires documenting precision, matrix shape, scaling, units, norm choice, condition number, singular values, rank threshold, solver method, factorization, pivoting, tolerance, residuals, backward error where possible, perturbation behavior, random seeds, package versions, data uncertainty, and model assumptions. Numerical output should be interpreted as computed evidence under finite precision and assumptions, not as automatic truth.

Back to top ↑

Related Articles

• What Is Linear Algebra for Systems Modeling?
• Visualization of Vectors, Transformations, and State Spaces
• Decomposition Workflows for Systems Analysis
• Scientific Computing Workflows for Linear Algebra
• Reproducible Linear Algebra Workflows with Notebooks and Documentation
• Matrix Operations Across Modeling Languages
• Large-Scale Matrix Computation
• Sparse Matrices and Computational Efficiency
• Rank, Nullity, and Structural Dependence
• Determinants and Invertibility
• Inverse Matrices and Structural Recovery
• Overdetermined Systems and Least Squares Thinking
• Singular Value Decomposition
• Principal Component Analysis
• Optimization, Gradients, and Matrix Structure
• Interpretation, Approximation, and Responsible Mathematical Modeling
• Linear Algebra for Systems Modeling
• Scientific Computing for Systems Modeling

Back to top ↑

Further Reading

• Demmel, J.W. (1997) Applied Numerical Linear Algebra. Philadelphia, PA: SIAM. Available at: https://epubs.siam.org/doi/book/10.1137/1.9781611971446.
• 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.
• Higham, N.J. (2008) Functions of Matrices: Theory and Computation. Philadelphia, PA: SIAM. Available at: https://epubs.siam.org/doi/book/10.1137/1.9780898717778.
• Saad, Y. (2003) Iterative Methods for Sparse Linear Systems. 2nd edn. Philadelphia, PA: SIAM. Available at: https://www-users.cse.umn.edu/~saad/books.html.
• Strang, G. (2019) Linear Algebra and Learning from Data. Wellesley, MA: Wellesley-Cambridge Press. Available at: https://math.mit.edu/~gs/learningfromdata/.
• Trefethen, L.N. and Bau, D. (1997) Numerical Linear Algebra. Philadelphia, PA: SIAM. Available at: https://epubs.siam.org/doi/book/10.1137/1.9780898719574.
• Van der Vorst, H.A. (2003) Iterative Krylov Methods for Large Linear Systems. Cambridge: Cambridge University Press. Available at: https://doi.org/10.1017/CBO9780511615115.
• Watkins, D.S. (2010) Fundamentals of Matrix Computations. 3rd edn. Hoboken, NJ: Wiley. Available at: https://www.wiley.com/en-us/Fundamentals+of+Matrix+Computations%2C+3rd+Edition-p-9780470528334.
• Wilkinson, J.H. (1965) The Algebraic Eigenvalue Problem. Oxford: Clarendon Press. Available at: https://global.oup.com/academic/product/the-algebraic-eigenvalue-problem-9780198534181.

Back to top ↑

References

• Demmel, J.W. (1997) Applied Numerical Linear Algebra. Philadelphia, PA: SIAM. Available at: https://epubs.siam.org/doi/book/10.1137/1.9781611971446.
• 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.
• Higham, N.J. (2008) Functions of Matrices: Theory and Computation. Philadelphia, PA: SIAM. Available at: https://epubs.siam.org/doi/book/10.1137/1.9780898717778.
• Saad, Y. (2003) Iterative Methods for Sparse Linear Systems. 2nd edn. Philadelphia, PA: SIAM. Available at: https://www-users.cse.umn.edu/~saad/books.html.
• Strang, G. (2019) Linear Algebra and Learning from Data. Wellesley, MA: Wellesley-Cambridge Press. Available at: https://math.mit.edu/~gs/learningfromdata/.
• Trefethen, L.N. and Bau, D. (1997) Numerical Linear Algebra. Philadelphia, PA: SIAM. Available at: https://epubs.siam.org/doi/book/10.1137/1.9780898719574.
• Van der Vorst, H.A. (2003) Iterative Krylov Methods for Large Linear Systems. Cambridge: Cambridge University Press. Available at: https://doi.org/10.1017/CBO9780511615115.
• Watkins, D.S. (2010) Fundamentals of Matrix Computations. 3rd edn. Hoboken, NJ: Wiley. Available at: https://www.wiley.com/en-us/Fundamentals+of+Matrix+Computations%2C+3rd+Edition-p-9780470528334.
• Wilkinson, J.H. (1965) The Algebraic Eigenvalue Problem. Oxford: Clarendon Press. Available at: https://global.oup.com/academic/product/the-algebraic-eigenvalue-problem-9780198534181.

Back to top ↑