Inverse Functions and System Interpretation

Last Updated June 14, 2026

Inverse functions turn systems modeling around. Instead of asking how inputs produce outputs, they ask what input, state, parameter, pathway, or condition could have produced an observed output. This reversal is central to calibration, diagnosis, reconstruction, inverse problems, optimization, control, and interpretation. But it is also dangerous when the model is not truly reversible, when many causes can produce the same observation, or when small output errors create large input errors.

An inverse function is not simply algebra run backward. It depends on structure: one-to-one behavior, domain restrictions, monotonicity, local invertibility, branch selection, stability, measurement error, conditioning, and interpretive purpose. In systems modeling, inverse reasoning often asks more than “What is \(f^{-1}(y)\)?” It asks whether the recovered input is meaningful, unique, stable, and justified by the system being modeled.

This article develops inverse functions as both a formal calculus topic and a systems-modeling tool. It examines one-to-one mappings, domain and codomain distinctions, local versus global inverses, inverse derivatives, the inverse function theorem, identifiability, inverse problems, calibration, feedback interpretation, numerical conditioning, and responsible use in system interpretation.

Forward models explain how assumptions generate outcomes. Inverse reasoning explains how outcomes may constrain assumptions. That reversal is powerful, but it requires discipline. A model can be easy to compute forward and difficult to interpret backward. The inverse direction may be nonunique, unstable, locally valid only, branch-dependent, or impossible without additional information.

Why Inverse Functions Matter

Inverse functions matter because many modeling questions begin with observed outcomes and ask what produced them. A sensor reading suggests a hidden state. A measured concentration suggests an emissions pathway. An observed disease prevalence suggests possible transmission parameters. A target risk level suggests required mitigation. A calibrated model parameter is chosen because it makes simulated output match observed data.

In a forward model, the direction is:

In inverse reasoning, the direction is reversed:

The phrase “when such recovery is valid” is essential. Inverse interpretation requires more than a formal symbol. It requires that the output determine the input uniquely or at least with documented ambiguity. It requires that the recovered input lie in a meaningful domain. It requires stability: small errors in \(y\) should not cause unreasonable changes in recovered \(x\). It requires a model whose inverse direction is substantively interpretable.

Systems modeling often fails when inverse reasoning is treated too casually. A model may fit an observation, but that does not mean it has identified the true cause. Many parameter combinations may produce similar outputs. A noisy observation may imply a wide range of possible states. A local inverse may exist in one regime and fail near a threshold. An inverse may be mathematically defined but practically useless because it is ill-conditioned.

Inverse functions therefore connect calculus with diagnosis, calibration, identifiability, uncertainty, and responsible inference.

Back to top ↑

Forward and Inverse Thinking

Forward modeling and inverse interpretation answer different questions.

Forward models can be many-to-one. Several inputs may lead to the same output. In that case, the inverse is not a function unless the domain is restricted or additional information is supplied. For example, \(f(x)=x^2\) does not have a global inverse on all real numbers because both \(x=2\) and \(x=-2\) produce \(y=4\). But if the domain is restricted to \(x\geq 0\), the inverse \(f^{-1}(y)=\sqrt{y}\) is well defined.

This simple example captures a major systems issue. Inverse interpretation often depends on domain restrictions. A recovered parameter may be unique only under a selected model class. A hidden state may be identifiable only if the system is restricted to a particular regime. A target pathway may be feasible only under policy, physical, or behavioral constraints.

Inverse thinking is not less mathematical than forward modeling. It usually requires more attention to assumptions, because reversing a model exposes nonuniqueness, instability, and missing information.

Back to top ↑

One-to-One Behavior and Domain Restrictions

A function \(f:A\to B\) is one-to-one if different inputs produce different outputs:

Equivalently:

One-to-one behavior is what allows a global inverse function to exist on the chosen domain. But systems models often violate it. A single observed outcome may be compatible with many causes. A risk score may compress several different risk profiles into one number. A model output may summarize a trajectory and lose information about the path that produced it. A sensor reading may be consistent with multiple states.

Domain restriction is the usual remedy. Instead of asking for an inverse over the entire mathematical space, modelers restrict attention to feasible states, admissible parameters, physically meaningful ranges, policy-relevant regimes, monotonic branches, or calibrated model classes.

This notation matters. The inverse depends not only on the formula but on the domain and codomain. The expression \(x^2\) can be invertible on \([0,\infty)\), invertible on \((-\infty,0]\), and not invertible on \(\mathbb{R}\). In systems modeling, this means inverse claims must name the admissible regime.

Back to top ↑

Derivatives of Inverse Functions

If \(f\) is invertible and differentiable, the derivative of the inverse is governed by the reciprocal of the forward derivative. Starting from:

Differentiating both sides gives:

Thus:

This formula has a strong modeling interpretation. If the forward derivative \(f'(x)\) is large, small changes in input produce large changes in output, and the inverse may be relatively stable. If \(f'(x)\) is small, output barely changes with input, so recovering input from output becomes unstable. If \(f'(x)=0\), the local inverse derivative may fail or become infinite.

Inverse derivatives therefore reveal recoverability. A flat forward model is a poor inverse model. A small change in measured output may imply a large range of plausible input values. This is one reason calibration and inverse problems can be unstable even when the forward model is smooth and easy to compute.

Back to top ↑

The Inverse Function Theorem

The inverse function theorem gives local conditions under which a differentiable function has a differentiable inverse. In one dimension, if \(f\) is continuously differentiable near \(a\) and:

Then \(f\) has a differentiable local inverse near \(a\). The derivative of the inverse is:

In multiple dimensions, let \(F:\mathbb{R}^n\to\mathbb{R}^n\). If \(F\) is continuously differentiable near \(a\) and the Jacobian matrix \(J_F(a)\) is invertible, then \(F\) has a differentiable local inverse near \(a\), and:

This theorem is central for systems interpretation. It says that local recoverability depends on the forward model’s local linear map. If the Jacobian is invertible and well conditioned, small output changes correspond to controlled input changes. If the Jacobian is singular or nearly singular, inverse interpretation becomes unstable or impossible.

For systems modeling, the inverse function theorem should be read as a regularity test. It does not prove that the inverse is globally valid. It does not prove causal truth. It does not eliminate measurement error. It says that, under local smoothness and nonsingularity conditions, the model can be reversed locally in a differentiable way.

Back to top ↑

Local and Global Inverses

A global inverse exists when a function is one-to-one over its entire chosen domain. A local inverse may exist near a point even when the function is not globally one-to-one.

For example, \(f(x)=x^3-x\) is not globally one-to-one over all real numbers. But near many points where \(f'(x)\neq 0\), the function can still be inverted locally. This distinction is important in systems modeling because many relationships are locally reversible but globally ambiguous.

Policy and scientific interpretation often confuse local and global inverses. A model calibrated near one regime may not be invertible across another. A diagnostic relation may work within ordinary operating conditions but fail near thresholds. A control relationship may be reversible near equilibrium but not under stress. A machine-learning model may provide gradients for optimization while still lacking a meaningful inverse explanation.

Responsible inverse interpretation must specify the scale of the claim: local, branch-specific, regime-specific, approximate, probabilistic, or global.

Back to top ↑

Identifiability and Recoverability

Identifiability asks whether model parameters or hidden states can be recovered from observations. It is the systems-modeling version of asking whether an inverse exists.

Suppose a model maps parameters \(\theta\) to outputs \(y\):

The inverse question is:

If different parameter values produce the same or nearly the same output, the parameters are not uniquely identifiable from those observations. In practical modeling, exact equality is not the only issue. If many parameters produce nearly indistinguishable outputs under measurement error, the inverse is practically weak even if it is mathematically unique.

Identifiability depends on model structure, observations, noise, domain restrictions, and experimental design. A parameter may be identifiable with one dataset and not another. A hidden state may be recoverable with enough sensors but ambiguous with a single aggregate indicator. A model may be locally identifiable near one parameter value and not near another.

Inverse functions therefore provide a calculus lens on identifiability. The derivative or Jacobian of the forward map reveals which directions in parameter space are visible in the output. Directions that are collapsed, nearly collapsed, or poorly scaled become hard to recover.

Back to top ↑

Inverse Problems in Systems Modeling

An inverse problem uses observations to infer hidden causes, parameters, states, structures, or inputs. Inverse problems appear throughout systems modeling:

• estimating emissions from observed atmospheric concentration;
• recovering disease transmission parameters from incidence data;
• inferring infrastructure stress from sensor measurements;
• calibrating model parameters to observed time series;
• estimating source locations from diffusion patterns;
• finding policy inputs that meet a target outcome;
• reconstructing initial conditions from later states.

Many inverse problems are not exact inverse-function problems. They may be overdetermined, underdetermined, noisy, probabilistic, constrained, or regularized. Instead of solving \(x=f^{-1}(y)\), analysts may solve an optimization problem:

This formulation acknowledges that exact inversion may be impossible or irresponsible. The observed output may contain noise. The forward model may be approximate. The parameter may not be unique. The regularization term \(R(\theta)\) encodes additional assumptions about plausible solutions.

Inverse problems are powerful because they connect observations to models. But they are also high-risk interpretive tools because the recovered answer may reflect assumptions, constraints, priors, smoothing choices, or optimization settings as much as the observed data.

Back to top ↑

Conditioning and Stability

Conditioning measures how sensitive a recovered input is to changes or errors in output. In one dimension, the inverse derivative:

If \(f'(x)\) is close to zero, then a small measurement error in \(y\) can produce a large error in recovered \(x\). This is a warning sign for calibration, diagnosis, and inverse interpretation.

In multiple dimensions, conditioning is tied to the Jacobian. If \(J_F(x)\) is ill-conditioned, then some output perturbations correspond to large input changes. The inverse may exist formally but be numerically unreliable.

This is why inverse workflows should include sensitivity and uncertainty checks. A recovered parameter should be reported with uncertainty, conditioning diagnostics, and local validity warnings. A precise-looking inverse value may hide a fragile inference.

In systems modeling, stability is not just numerical. It is interpretive. If small observation errors, model errors, or regime assumptions drastically change the recovered state, then the inverse should be treated as a scenario-dependent reconstruction rather than a robust finding.

Back to top ↑

Branch Selection and Interpretive Ambiguity

Many inverse relationships require branch selection. A branch is a restricted part of a relationship where inversion becomes possible. For example, \(y=x^2\) has two branches: \(x=\sqrt{y}\) and \(x=-\sqrt{y}\). The correct branch is not determined by algebra alone. It depends on the domain and the interpretation.

In systems modeling, branch selection appears when:

• multiple parameter combinations fit the same data;
• multiple equilibrium states exist;
• a system has low and high regimes for the same control value;
• a threshold model has pre-threshold and post-threshold branches;
• a diagnostic measure is compatible with several system states;
• a nonlinear calibration surface has multiple minima.

Branch selection must be documented. It may be based on physical constraints, historical context, prior observations, policy assumptions, stability criteria, or feasibility conditions. Without such documentation, an inverse result can appear more certain than it is.

Ambiguity is not always a failure. Sometimes the correct conclusion is that the observation does not determine a unique state. That conclusion may be more useful than selecting a false precision. Inverse functions are powerful partly because they reveal when a system is not recoverable from available information.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer for mathematically advanced readers. Inverse-function reasoning is fundamentally about structure: injectivity, surjectivity onto an image, local diffeomorphism, derivative invertibility, conditioning, and domain choice. The inverse is not attached to a formula alone; it is attached to a function with a specified domain, codomain, and image.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for inverse functions should record the forward model, admissible domain, target output, recovered input, residual error, derivative or Jacobian at the recovered input, inverse sensitivity, conditioning warning, and branch or domain restriction. They should also test whether the forward model evaluated at the recovered input reproduces the target output.

For one-dimensional inverse problems, root-finding may solve \(f(x)-y_{\mathrm{target}}=0\). For multidimensional inverse problems, nonlinear solvers, least-squares methods, regularization, Bayesian inference, or constrained optimization may be required. In all cases, the inverse result should be treated as a model-dependent reconstruction rather than an automatic fact.

A reproducible inverse workflow should ask:

• Is the forward model one-to-one on the chosen domain?
• Is the recovered input inside the admissible domain?
• Is the derivative or Jacobian nonsingular at the recovered input?
• Is the inverse sensitivity stable enough to interpret?
• Could other inputs produce the same or nearly the same output?
• How does measurement error propagate backward into recovered inputs?

These checks turn inverse modeling into an auditable interpretive process rather than a hidden algebraic reversal.

Back to top ↑

Python Workflow: Inverse Interpretation Audit

The Python workflow below recovers an input from a target output for a simple monotonic forward model and records inverse sensitivity.

from __future__ import annotations

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


@dataclass(frozen=True)
class InverseAudit:
    target_output: float
    recovered_input: float
    forward_check: float
    residual: float
    forward_derivative: float
    inverse_sensitivity: float
    domain_valid: bool
    warning: str


def forward_model(x: float) -> float:
    # Monotonic teaching model: y = log(1 + x), valid for x > -1.
    return math.log1p(x)


def forward_derivative(x: float) -> float:
    return 1.0 / (1.0 + x)


def inverse_model(y: float) -> float:
    return math.exp(y) - 1.0


def inverse_audit(target_output: float) -> InverseAudit:
    x = inverse_model(target_output)
    y_check = forward_model(x)
    residual = y_check - target_output
    derivative = forward_derivative(x)
    inverse_sensitivity = 1.0 / derivative

    domain_valid = x > -1.0
    warning = ""
    if not domain_valid:
        warning = "recovered input outside domain"
    elif abs(derivative) < 1e-6:
        warning = "small forward derivative; inverse may be unstable"
    elif abs(residual) > 1e-8:
        warning = "forward check does not reproduce target output"

    return InverseAudit(
        target_output=target_output,
        recovered_input=x,
        forward_check=y_check,
        residual=residual,
        forward_derivative=derivative,
        inverse_sensitivity=inverse_sensitivity,
        domain_valid=domain_valid,
        warning=warning
    )


rows = [inverse_audit(y) for y in [0.0, 0.5, 1.0, 1.5, 2.0]]

output_dir = Path("outputs/tables")
output_dir.mkdir(parents=True, exist_ok=True)

with (output_dir / "inverse_interpretation_audit.csv").open("w", newline="", encoding="utf-8") as handle:
    writer = csv.DictWriter(handle, fieldnames=asdict(rows[0]).keys())
    writer.writeheader()
    for row in rows:
        writer.writerow(asdict(row))

print("Wrote inverse interpretation audit.")

This workflow checks the forward model after inversion, records derivative-based inverse sensitivity, and warns when the inverse may be unstable or invalid.

Back to top ↑

R Workflow: Recoverability and Sensitivity

The R workflow below performs the same inverse audit using base R.

# Inverse Functions and System Interpretation
# Base R workflow for inverse recoverability and sensitivity.

forward_model <- function(x) {
  log1p(x)
}

forward_derivative <- function(x) {
  1 / (1 + x)
}

inverse_model <- function(y) {
  exp(y) - 1
}

inverse_audit <- function(target_output) {
  x <- inverse_model(target_output)
  y_check <- forward_model(x)
  residual <- y_check - target_output
  derivative <- forward_derivative(x)
  inverse_sensitivity <- 1 / derivative

  domain_valid <- x > -1
  warning <- ""
  if (!domain_valid) {
    warning <- "recovered input outside domain"
  } else if (abs(derivative) < 1e-6) {
    warning <- "small forward derivative; inverse may be unstable"
  } else if (abs(residual) > 1e-8) {
    warning <- "forward check does not reproduce target output"
  }

  data.frame(
    target_output = target_output,
    recovered_input = x,
    forward_check = y_check,
    residual = residual,
    forward_derivative = derivative,
    inverse_sensitivity = inverse_sensitivity,
    domain_valid = domain_valid,
    warning = warning
  )
}

results <- do.call(rbind, lapply(c(0, 0.5, 1, 1.5, 2), inverse_audit))

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

print(results)

The workflow makes inverse interpretation auditable by pairing recovered inputs with forward checks and sensitivity warnings.

Back to top ↑

Haskell Workflow: Typed Inverse Records

Haskell can keep target outputs, recovered inputs, forward checks, and sensitivity records distinct through typed wrappers.

module Main where

newtype Output = Output Double deriving (Show)
newtype Input = Input Double deriving (Show)
newtype Sensitivity = Sensitivity Double deriving (Show)
newtype Residual = Residual Double deriving (Show)

data InverseAudit = InverseAudit
  { targetOutput :: Output
  , recoveredInput :: Input
  , forwardCheck :: Output
  , residualValue :: Residual
  , forwardSensitivity :: Sensitivity
  , inverseSensitivity :: Sensitivity
  , warning :: String
  } deriving (Show)

forwardModel :: Input -> Double
forwardModel (Input x) =
  log (1.0 + x)

forwardDerivative :: Input -> Double
forwardDerivative (Input x) =
  1.0 / (1.0 + x)

inverseModel :: Output -> Double
inverseModel (Output y) =
  exp y - 1.0

inverseAudit :: Output -> InverseAudit
inverseAudit y@(Output target) =
  let xValue = inverseModel y
      x = Input xValue
      yCheck = forwardModel x
      derivative = forwardDerivative x
      invSensitivity = 1.0 / derivative
      residual = yCheck - target
      warningText =
        if xValue <= (-1.0) then "recovered input outside domain"
        else if abs derivative < 1.0e-6 then "small forward derivative"
        else if abs residual > 1.0e-8 then "forward check residual"
        else ""
  in InverseAudit
      { targetOutput = y
      , recoveredInput = x
      , forwardCheck = Output yCheck
      , residualValue = Residual residual
      , forwardSensitivity = Sensitivity derivative
      , inverseSensitivity = Sensitivity invSensitivity
      , warning = warningText
      }

main :: IO ()
main = do
  mapM_ (print . inverseAudit . Output) [0.0, 0.5, 1.0, 1.5, 2.0]

The typed representation helps prevent the recovered input from being confused with the observed output or the derivative-based sensitivity.

Back to top ↑

SQL Workflow: Inverse-Model Assumption Registry

SQL can document inverse-model assumptions and audit warnings for system interpretation.

CREATE TABLE inverse_model_assumption_registry (
    assumption_key TEXT PRIMARY KEY,
    assumption_name TEXT NOT NULL,
    mathematical_role TEXT NOT NULL,
    systems_modeling_role TEXT NOT NULL,
    review_warning TEXT NOT NULL
);

INSERT INTO inverse_model_assumption_registry VALUES
(
  'domain_restriction',
  'Domain restriction',
  'The inverse is defined relative to a specified admissible domain.',
  'Identifies the regime, branch, or feasible set under which recovery is meaningful.',
  'Changing the domain can change or destroy the inverse.'
);

INSERT INTO inverse_model_assumption_registry VALUES
(
  'injectivity',
  'Injectivity',
  'Different admissible inputs must produce different outputs.',
  'Supports uniqueness of recovered states or parameters.',
  'If the forward model is many-to-one, inverse interpretation is ambiguous.'
);

INSERT INTO inverse_model_assumption_registry VALUES
(
  'local_invertibility',
  'Local invertibility',
  'A nonzero derivative or invertible Jacobian supports local inverse recovery.',
  'Allows local reconstruction near an operating point.',
  'Local invertibility does not imply global invertibility.'
);

INSERT INTO inverse_model_assumption_registry VALUES
(
  'conditioning',
  'Conditioning',
  'Inverse sensitivity depends on the reciprocal derivative or inverse Jacobian.',
  'Shows whether recovered inputs are stable under output noise.',
  'Ill-conditioned inverse maps can make precise recovery misleading.'
);

INSERT INTO inverse_model_assumption_registry VALUES
(
  'identifiability',
  'Identifiability',
  'Parameters or states must be recoverable from available outputs.',
  'Connects inverse functions with calibration and diagnosis.',
  'Similar outputs from different inputs weaken interpretive claims.'
);

SELECT
    assumption_name,
    mathematical_role,
    systems_modeling_role,
    review_warning
FROM inverse_model_assumption_registry
ORDER BY assumption_key;

This registry makes inverse interpretation reviewable. It documents domain restrictions, uniqueness, local invertibility, conditioning, and identifiability.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It supports inverse interpretation audits, recoverability checks, domain and branch review, inverse derivative calculations, local invertibility diagnostics, identifiability warnings, conditioning review, typed inverse records, inverse-model assumption registries, reproducible notebooks, documentation, generated outputs, and advanced mathematical audit reports.

Back to top ↑

Interpretive Limits and Responsible Use

Inverse functions can make systems interpretable, but they can also encourage overconfident reconstruction. A recovered input is not automatically the true cause of an output. It is the input recovered under a specific model, domain, branch, data condition, and uncertainty structure.

Responsible use requires several checks. State the forward model. Specify the domain and codomain. Identify the image on which the inverse is defined. Check injectivity or document nonuniqueness. Distinguish local inverse claims from global inverse claims. Report derivative or Jacobian conditioning. Test forward consistency by evaluating the forward model at the recovered input. Document measurement error, model error, and branch selection. Avoid treating calibration as proof of causal uniqueness.

The central modeling question is not only “What is the inverse?” It is “Under what assumptions is this reversal meaningful, unique, stable, and useful for system interpretation?”

Back to top ↑

Related Articles

• Calculus for Systems Modeling
• Implicit Differentiation and Coupled Relationships
• The Chain Rule and Composite Change in Interacting Systems
• The Quotient Rule and Relative Change
• Rules of Differentiation and Model Structure
• Derivatives and Rates of Change
• Partial Derivatives and Multivariable Change
• Gradients, Jacobians, and Vector Fields
• Model Calibration and Parameter Estimation
• Scientific Computing for Systems Modeling

Back to top ↑

Further Reading

• Apostol, T.M. (1967) Calculus, Volume 1: One-Variable Calculus, with an Introduction to Linear Algebra. 2nd edn. New York: Wiley.
• Spivak, M. (2008) Calculus. 4th edn. Houston, TX: Publish or Perish.
• Rudin, W. (1976) Principles of Mathematical Analysis. 3rd edn. New York: McGraw-Hill.
• Abbott, S. (2015) Understanding Analysis. 2nd edn. New York: Springer.
• Courant, R. and John, F. (1999) Introduction to Calculus and Analysis, Volume I. Berlin: Springer.
• Hubbard, J.H. and Hubbard, B.B. (2015) Vector Calculus, Linear Algebra, and Differential Forms: A Unified Approach. 5th edn. Ithaca, NY: Matrix Editions.
• Krantz, S.G. and Parks, H.R. (2013) The Implicit Function Theorem: History, Theory, and Applications. New York: Birkhäuser.
• Vogel, C.R. (2002) Computational Methods for Inverse Problems. Philadelphia, PA: Society for Industrial and Applied Mathematics.
• Kaipio, J. and Somersalo, E. (2005) Statistical and Computational Inverse Problems. New York: Springer.
• Massachusetts Institute of Technology (MIT) OpenCourseWare (2010) Single Variable Calculus. Cambridge, MA: MIT OpenCourseWare.
• Massachusetts Institute of Technology (MIT) OpenCourseWare (2020) Real Analysis. Cambridge, MA: MIT OpenCourseWare.
• OpenStax (2016a) Calculus Volume 1. Houston, TX: OpenStax, Rice University.

Back to top ↑

References

• Abbott, S. (2015) Understanding Analysis. 2nd edn. New York: Springer.
• Apostol, T.M. (1967) Calculus, Volume 1: One-Variable Calculus, with an Introduction to Linear Algebra. 2nd edn. New York: Wiley.
• Courant, R. and John, F. (1999) Introduction to Calculus and Analysis, Volume I. Berlin: Springer.
• Hubbard, J.H. and Hubbard, B.B. (2015) Vector Calculus, Linear Algebra, and Differential Forms: A Unified Approach. 5th edn. Ithaca, NY: Matrix Editions.
• Kaipio, J. and Somersalo, E. (2005) Statistical and Computational Inverse Problems. New York: Springer.
• Krantz, S.G. and Parks, H.R. (2013) The Implicit Function Theorem: History, Theory, and Applications. New York: Birkhäuser.
• Massachusetts Institute of Technology (MIT) OpenCourseWare (2010) Single Variable Calculus. Cambridge, MA: MIT OpenCourseWare.
• Massachusetts Institute of Technology (MIT) OpenCourseWare (2020) Real Analysis. Cambridge, MA: MIT OpenCourseWare.
• OpenStax (2016a) Calculus Volume 1. Houston, TX: OpenStax, Rice University.
• Rudin, W. (1976) Principles of Mathematical Analysis. 3rd edn. New York: McGraw-Hill.
• Spivak, M. (2008) Calculus. 4th edn. Houston, TX: Publish or Perish.
• Vogel, C.R. (2002) Computational Methods for Inverse Problems. Philadelphia, PA: Society for Industrial and Applied Mathematics.

Back to top ↑