Limits and the Formal Basis of Calculus

Last Updated June 14, 2026

Limits provide the formal basis of calculus. They make precise the ideas that earlier calculus expressed through motion, infinitesimals, vanishing intervals, and infinite refinement. A derivative is a limit of difference quotients. An integral is a limit of sums. Continuity is defined by preservation of limits. Infinite series, asymptotic behavior, numerical convergence, equilibrium analysis, and stability all depend on limit reasoning.

For systems modeling, limits are not only classroom abstractions. They clarify how local rates are inferred from finite observations, how discrete simulations approximate continuous processes, how accumulated effects emerge from many small contributions, and how long-run behavior can be interpreted without confusing computation with reality. A model of population growth, resource depletion, infrastructure fatigue, disease transmission, climate forcing, or economic compounding often depends on a limiting argument, even when the final implementation runs on finite data and finite machines.

This article explains limits as the formal foundation of calculus and as a practical discipline for systems modeling. It begins with intuitive limiting behavior, then develops epsilon-delta definitions, sequential formulations, one-sided and infinite limits, continuity, derivatives, integrals, convergence of functions, counterexamples, and numerical approximation. It also adds a mathematical deepening section for readers who need a more rigorous account of domains, topological structure, uniform convergence, interchange of limits, and pathological cases.

Limits answer a central question: what does a quantity approach as inputs, intervals, partitions, time steps, or sequences move toward a target? This question appears in pure mathematics and in applied modeling. It appears when an average rate becomes an instantaneous rate, when a sum becomes an integral, when a sequence approaches equilibrium, when a simulation step shrinks, when an estimator converges, and when a system tends toward long-run behavior.

Why Limits Matter

Calculus needs limits because many of its central objects are not ordinary finite comparisons. The slope of a secant line over a nonzero interval is easy to compute. The slope at a point requires a limiting process. The sum of finitely many rectangles is easy to compute. The area under a curve requires a limiting process over finer partitions. The behavior of a sequence after finitely many terms can be inspected directly. Its long-run behavior requires a limiting argument.

Limits make these transitions precise. They define what it means for values to approach a target, even when the target is not reached in the ordinary computation. They let mathematicians distinguish convergence from divergence, removable discontinuities from essential behavior, local stability from instability, and reliable approximation from misleading numerical coincidence.

In systems modeling, limit reasoning appears whenever finite observations are used to represent continuous processes. A model may use monthly data to infer a continuous rate, a finite grid to approximate a spatial field, a small time step to simulate a differential equation, or a long simulation to approximate equilibrium behavior. Each of these tasks depends on assumptions about convergence, approximation, continuity, and scale.

Without limits, calculus would remain a collection of informal procedures. With limits, calculus becomes a rigorous framework for local change, accumulation, approximation, and long-run analysis.

Back to top ↑

From Intuition to Formalization

Informally, a limit describes the value a function approaches as its input approaches some point. For example, a model output may approach a stable equilibrium as time increases, or a difference quotient may approach a derivative as the interval length shrinks. This intuitive idea is useful, but it is not enough for mathematical rigor.

The difficulty is that approaching is not the same as arriving. A function may approach a value without ever equaling it. A sequence may get arbitrarily close to a number without reaching it. A simulation may appear to settle into a pattern but later diverge. A function may behave differently depending on the direction from which the input approaches a point.

Formal limits answer these ambiguities by replacing visual intuition with quantified conditions. Instead of saying that \(f(x)\) gets close to \(L\), the formal definition says that for every output tolerance, there exists an input tolerance that guarantees the output lies within the chosen tolerance. This turns approximation into a precise mathematical claim.

The shift from intuition to formalization matters for modeling because models often rely on approximate language: small change, near equilibrium, sufficiently fine grid, long enough simulation, stable output, negligible error. Limit definitions force the analyst to ask what “small,” “near,” “fine,” “long,” “stable,” and “negligible” actually mean.

Back to top ↑

The Epsilon-Delta Definition

The classical epsilon-delta definition gives a precise meaning to the limit of a function at a point.

Formally:

This definition has several important features. First, it does not require \(f(a)\) to exist. Second, it does not require \(f(a)=L\). Third, it only concerns behavior near \(a\), not necessarily at \(a\). Fourth, it is local: the function may behave wildly elsewhere and still have a limit at \(a\).

For systems modeling, this distinction is useful. A model may have local behavior near an operating point even if it fails elsewhere. A rate may be meaningful near a state but not globally. A threshold may create one-sided behavior. A calibration may support local approximation but not large extrapolation.

The epsilon-delta definition also reminds modelers that limits depend on domains. The condition \(0<|x-a|<\delta\) must be interpreted relative to the domain of the function. If a model is only defined on a feasible set, then the limiting process must occur through admissible points of that set.

Back to top ↑

Sequential and Topological Formulations

For real-valued functions on subsets of \(\mathbb{R}\), limits can also be characterized by sequences. A function \(f\) has limit \(L\) at \(a\) if every sequence \((x_n)\) in the domain, with \(x_n\neq a\) and \(x_n\to a\), satisfies \(f(x_n)\to L\).

The sequential formulation is especially useful for counterexamples. To show that a limit does not exist, it is often enough to construct two sequences approaching the same point but producing different limiting outputs.

In more general spaces, limits are often expressed topologically. A function \(f:X\to Y\) between topological spaces has limit \(L\) at \(a\) if the values of \(f(x)\) eventually lie in every neighborhood of \(L\) whenever \(x\) lies sufficiently close to \(a\), excluding \(a\) if necessary. In metric spaces, this reduces to distance-based epsilon-delta language.

For advanced systems modeling, the topological view matters because models may operate in spaces more complicated than the real line: vector spaces, function spaces, probability spaces, manifolds, networks, state spaces, and spaces of parameters. The idea of approaching a point depends on the structure of the space. A norm, metric, topology, or convergence mode must be specified.

This is not technical ornament. A sequence of functions may converge pointwise but not uniformly. A sequence of probability distributions may converge weakly but not in total variation. A numerical solution may converge in one norm but not another. In modeling, the chosen notion of convergence affects what the result means.

Back to top ↑

One-Sided, Infinite, and Extended Limits

Not all limits are two-sided finite limits. Many systems have boundaries, thresholds, capacity constraints, or asymptotic regimes. One-sided and infinite limits help describe these cases.

A right-hand limit examines behavior as \(x\) approaches \(a\) from values greater than \(a\):

A left-hand limit examines behavior from below:

A two-sided limit exists only when the left-hand and right-hand limits agree. This matters in models with thresholds. A policy rule, infrastructure capacity limit, ecological tipping point, or discontinuous intervention may produce different behavior on opposite sides of a boundary.

Infinite limits describe unbounded behavior:

Limits at infinity describe long-run behavior:

In applied models, infinite limits require caution. Mathematical infinity may describe a trend, asymptote, singularity, or idealization. It should not be confused with physically measurable infinity. A model that “goes to infinity” may be revealing an actual unbounded process, but it may also be revealing that the model has left its valid domain.

Back to top ↑

Limit Laws and Preservation Results

Limit laws explain when limits are preserved under algebraic operations. If \(f(x)\to L\) and \(g(x)\to M\) as \(x\to a\), then, under ordinary finite conditions:

These laws make calculus workable, but they are conditional. They depend on the existence of limits and on restrictions such as nonzero denominators. In modeling, those restrictions matter. A ratio model may fail near zero. A normalized index may become unstable when the scaling factor is small. A rate per unit population may become meaningless as population approaches zero.

Limit laws also support composition. If \(g(x)\to M\) and \(f\) is continuous at \(M\), then \(f(g(x))\to f(M)\). This is one reason continuity is so central: continuous functions preserve limiting behavior.

Back to top ↑

Continuity as Limit Preservation

A function is continuous at \(a\) when the limit of the function as \(x\to a\) equals the value of the function at \(a\):

Continuity matters because calculus relies on stable local behavior. If a function is continuous, small changes in input do not produce sudden jumps in output. If a function is discontinuous, derivative-based reasoning may fail, integration may require care, and numerical methods may behave poorly.

Systems models often assume continuity even when real systems contain thresholds, shocks, delays, discrete events, or policy discontinuities. This assumption may be reasonable at some scales and misleading at others. A model of daily average temperature may be effectively continuous. A model of infrastructure failure may be discontinuous at rupture. A model of policy eligibility may jump at a threshold. A model of disease control may change abruptly when an intervention begins.

Continuity should therefore be treated as a modeling assumption, not a default property of reality.

Back to top ↑

Derivatives and Integrals as Limits

The derivative is the limit of a difference quotient:

The derivative exists only if this limit exists. A function can be continuous but not differentiable. It can have a corner, cusp, vertical tangent, oscillation, or other local behavior that prevents a stable derivative. This distinction matters for systems modeling because smooth curves in visualizations may hide nonsmooth mechanisms.

The integral can also be defined as a limit, often through Riemann sums:

This matters for stock-flow systems. A stock changes because flows accumulate over time. The integral formalizes the accumulation of continuously varying flow. But the interpretation depends on integrability, units, domain validity, and the meaning of the flow over the interval.

In computational modeling, neither the derivative nor the integral is computed through an actual infinite process. Instead, numerical methods approximate the limiting object. The mathematical definition explains the target; the computational method produces an approximation whose error must be understood.

Back to top ↑

Pointwise and Uniform Convergence

Advanced modeling often works not only with limits of numbers, but with limits of functions. A sequence of functions \((f_n)\) may converge to a function \(f\) in different senses.

Pointwise convergence means that for each fixed input \(x\), the sequence \(f_n(x)\) converges to \(f(x)\):

Uniform convergence is stronger:

The distinction is crucial. Pointwise limits may fail to preserve continuity, integrability, differentiability, or stability properties. Uniform convergence often allows stronger conclusions. In numerical modeling, convergence at selected points does not guarantee reliable behavior across the full domain or feasible region.

This is especially important for surrogate models, reduced-order models, interpolation schemes, machine-learning approximations, finite-element approximations, and discretized simulations. A model can converge on sampled points while failing near boundaries, discontinuities, rare scenarios, or high-curvature regions.

Mathematically mature systems modeling should therefore ask: convergence where, in what norm, over which domain, and with what preservation properties?

Back to top ↑

Pathologies, Counterexamples, and Boundary Cases

Limits are powerful partly because they expose failure. A function may look well behaved in a graph but lack a limit at a point. A sequence may appear stable for many terms but fail to converge. A numerical approximation may improve for a while and then degrade because of roundoff error. A family of functions may converge pointwise to a discontinuous limit.

Classic counterexamples are not distractions from applied modeling. They teach caution. For example, the function

This kind of behavior matters for models with rapid oscillation, instability, or unresolved scale effects. A model output may fail to approach a stable value even as the input approaches a target.

Another example is a removable discontinuity:

This distinction is important in data and modeling. A missing or undefined value at a point does not necessarily destroy limiting behavior, but it does require careful treatment.

Boundary cases also matter. A function may have a derivative in the interior of a domain but not at the boundary. An optimization problem may attain its maximum at a boundary where first-order interior conditions fail. A differential equation may preserve an invariant set only under certain parameter restrictions. A numerical method may leave the valid state space even when the true continuous system does not.

Pathologies remind modelers that formal definitions are protective. They prevent visual intuition and computational convenience from being mistaken for mathematical validity.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer for mathematically advanced readers. Limits are not one idea with one universal meaning. They depend on domain, codomain, topology, metric, convergence mode, and the operation being preserved.

Back to top ↑

Limits in Systems Modeling

Systems modeling uses limits in at least five recurring ways. First, local rates are limits of average changes. Second, accumulations are limits of finite sums. Third, equilibrium behavior is often expressed as a limit as time goes to infinity. Fourth, numerical methods approximate limiting objects through finite algorithms. Fifth, model refinement asks whether results stabilize as resolution improves.

For example, a discrete-time simulation may approximate a continuous-time differential equation. As the time step decreases, the simulation should approach the continuous solution under suitable conditions. If it does not, the method may be unstable, inconsistent, or applied outside its valid regime.

A climate model may study limiting temperature response under a forcing pathway. An epidemiological model may examine whether infection tends toward extinction or endemic equilibrium. A resource model may examine whether a stock approaches a sustainable level or collapses. An infrastructure model may examine whether stress approaches a failure threshold. An economic model may examine long-run convergence or divergence under compounding dynamics.

In each case, the limiting result is not simply an output. It is a statement about behavior under assumptions. The analyst must specify what is approaching what, under which topology or metric, over which domain, and with what empirical interpretation.

Back to top ↑

Examples Across Systems Modeling

These examples show that limit language is everywhere in systems modeling, but its meaning changes with context. A responsible model should specify the limiting process and the assumptions that make the limit meaningful.

Back to top ↑

Computation and Reproducible Workflows

Computers do not compute mathematical limits directly. They compute finite approximations. A numerical derivative uses a finite step. A numerical integral uses a finite partition. A simulation uses finite time steps. A convergence study evaluates whether outputs stabilize as resolution changes.

This means computational workflows should not merely report a final number. They should record step sizes, error estimates, convergence order, stability warnings, roundoff behavior, and domain checks. A result should be accompanied by evidence that the approximation is behaving as expected.

For an advanced calculus companion workflow, the minimum standard should include forward differences, central differences, Richardson extrapolation, convergence-order estimates, and roundoff review. When the model involves state trajectories, it should also include invariant-set checks to verify that numerical approximations remain in the valid state space.

The workflows below illustrate this standard in Python, R, Haskell, and SQL.

Back to top ↑

Python Workflow: Numerical Limits and Convergence Order

This Python workflow compares forward difference, central difference, and Richardson extrapolation. It also estimates empirical convergence order and records roundoff warnings.

from __future__ import annotations

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


@dataclass(frozen=True)
class LimitExperiment:
    method: str
    x: float
    h: float
    estimate: float
    exact: float
    absolute_error: float


def f(x: float) -> float:
    return math.exp(0.2 * x)


def exact_derivative(x: float) -> float:
    return 0.2 * math.exp(0.2 * x)


def forward_difference(x: float, h: float) -> float:
    if h <= 0:
        raise ValueError("h must be positive")
    return (f(x + h) - f(x)) / h


def central_difference(x: float, h: float) -> float:
    if h <= 0:
        raise ValueError("h must be positive")
    return (f(x + h) - f(x - h)) / (2.0 * h)


def richardson_extrapolation(central_h: float, central_h_over_2: float) -> float:
    # Central difference is second-order for smooth functions.
    return (4.0 * central_h_over_2 - central_h) / 3.0


def estimate_order(error_large: float, error_small: float, ratio: float = 2.0) -> float:
    if error_large <= 0 or error_small <= 0:
        return float("nan")
    return math.log(error_large / error_small) / math.log(ratio)


x0 = 5.0
h_values = [1.0, 0.5, 0.25, 0.125, 0.0625, 0.03125, 0.015625]
exact = exact_derivative(x0)

rows: list[LimitExperiment] = []

for h in h_values:
    fd = forward_difference(x0, h)
    cd = central_difference(x0, h)
    cd_half = central_difference(x0, h / 2.0)
    rich = richardson_extrapolation(cd, cd_half)

    rows.append(LimitExperiment("forward_difference", x0, h, fd, exact, abs(fd - exact)))
    rows.append(LimitExperiment("central_difference", x0, h, cd, exact, abs(cd - exact)))
    rows.append(LimitExperiment("richardson_central", x0, h, rich, exact, abs(rich - exact)))

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

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

# Estimate convergence order between successive step sizes.
order_rows = []
for method in sorted({row.method for row in rows}):
    method_rows = [row for row in rows if row.method == method]
    method_rows.sort(key=lambda item: item.h, reverse=True)

    for a, b in zip(method_rows, method_rows[1:]):
        order_rows.append({
            "method": method,
            "h_large": a.h,
            "h_small": b.h,
            "error_large": a.absolute_error,
            "error_small": b.absolute_error,
            "estimated_order": estimate_order(a.absolute_error, b.absolute_error, a.h / b.h),
        })

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

print("Wrote convergence study and estimated convergence orders.")

This workflow treats a derivative as a limiting object and the numerical estimate as an approximation with measurable behavior. It does not assume that a small \(h\) is automatically better. It generates evidence about error and convergence.

Back to top ↑

R Workflow: Epsilon Bands and Approximation Error

This R workflow examines whether approximations enter a selected epsilon band around the exact derivative.

# Limits and the Formal Basis of Calculus
# Base R epsilon-band and convergence workflow.

f <- function(x) {
  exp(0.2 * x)
}

exact_derivative <- function(x) {
  0.2 * exp(0.2 * x)
}

forward_difference <- function(x, h) {
  (f(x + h) - f(x)) / h
}

central_difference <- function(x, h) {
  (f(x + h) - f(x - h)) / (2 * h)
}

x0 <- 5.0
h_values <- c(1.0, 0.5, 0.25, 0.125, 0.0625, 0.03125, 0.015625)
epsilon <- 1e-4
exact <- exact_derivative(x0)

results <- data.frame(
  h = h_values,
  forward = forward_difference(x0, h_values),
  central = central_difference(x0, h_values)
)

results$forward_error <- abs(results$forward - exact)
results$central_error <- abs(results$central - exact)
results$forward_inside_epsilon <- results$forward_error < epsilon
results$central_inside_epsilon <- results$central_error < epsilon

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

print(results)

The epsilon band connects formal limit language to reproducible computation. Instead of saying that the approximation is “close,” the workflow specifies a tolerance and checks whether the numerical estimate satisfies it.

Back to top ↑

Haskell Workflow: Typed Limit Experiments

Haskell can make approximation records more explicit by separating step sizes, estimates, exact values, and errors.

module Main where

newtype Location = Location Double deriving (Show)
newtype StepSize = StepSize Double deriving (Show)
newtype Estimate = Estimate Double deriving (Show)
newtype Exact = Exact Double deriving (Show)
newtype AbsoluteError = AbsoluteError Double deriving (Show)

data Method
  = ForwardDifference
  | CentralDifference
  deriving (Show)

data LimitExperiment = LimitExperiment
  { method :: Method
  , location :: Location
  , stepSize :: StepSize
  , estimate :: Estimate
  , exactValue :: Exact
  , absoluteError :: AbsoluteError
  } deriving (Show)

systemResponse :: Location -> Double
systemResponse (Location x) =
  exp (0.2 * x)

exactDerivative :: Location -> Exact
exactDerivative (Location x) =
  Exact (0.2 * exp (0.2 * x))

forwardDifference :: Location -> StepSize -> Estimate
forwardDifference loc@(Location x) (StepSize h) =
  Estimate ((systemResponse (Location (x + h)) - systemResponse loc) / h)

centralDifference :: Location -> StepSize -> Estimate
centralDifference (Location x) (StepSize h) =
  Estimate ((systemResponse (Location (x + h)) - systemResponse (Location (x - h))) / (2 * h))

runExperiment :: Method -> Location -> StepSize -> LimitExperiment
runExperiment m loc h =
  let est@(Estimate e) =
        case m of
          ForwardDifference -> forwardDifference loc h
          CentralDifference -> centralDifference loc h
      exact@(Exact v) = exactDerivative loc
  in LimitExperiment
      { method = m
      , location = loc
      , stepSize = h
      , estimate = est
      , exactValue = exact
      , absoluteError = AbsoluteError (abs (e - v))
      }

main :: IO ()
main = do
  let loc = Location 5.0
  let steps = map StepSize [1.0, 0.5, 0.25, 0.125, 0.0625]
  mapM_ (print . runExperiment ForwardDifference loc) steps
  mapM_ (print . runExperiment CentralDifference loc) steps

The typed structure prevents the workflow from treating all numbers as interchangeable. A step size, estimate, exact comparison, and error have different modeling roles.

Back to top ↑

SQL Workflow: Limit Assumption Registry

SQL can store assumptions about limiting operations, convergence modes, and modeling risks. This makes the mathematical interpretation auditable across model runs.

CREATE TABLE limit_assumption_registry (
    assumption_key TEXT PRIMARY KEY,
    concept_name TEXT NOT NULL,
    formal_role TEXT NOT NULL,
    systems_modeling_role TEXT NOT NULL,
    review_warning TEXT NOT NULL
);

INSERT INTO limit_assumption_registry VALUES
(
  'epsilon_delta',
  'Epsilon-delta limit',
  'Defines local convergence of function values through quantified tolerances.',
  'Clarifies what it means for model outputs to approach a target under input refinement.',
  'Requires an admissible domain and a specified output metric.'
);

INSERT INTO limit_assumption_registry VALUES
(
  'sequential_limit',
  'Sequential characterization',
  'Tests limits through all admissible sequences approaching the target.',
  'Useful for identifying path-dependent or sequence-dependent model behavior.',
  'A single sequence is not enough to prove a limit, but two conflicting sequences can disprove one.'
);

INSERT INTO limit_assumption_registry VALUES
(
  'uniform_convergence',
  'Uniform convergence',
  'Controls convergence across an entire domain using a supremum norm.',
  'Supports stronger claims about global approximation behavior.',
  'Pointwise convergence alone may not preserve continuity or stability.'
);

INSERT INTO limit_assumption_registry VALUES
(
  'interchange_limits',
  'Interchange of limits and operations',
  'Concerns when limits commute with integration, differentiation, expectation, or optimization.',
  'Important for simulation, aggregation, uncertainty, and sensitivity analysis.',
  'Requires additional hypotheses such as domination, uniform convergence, compactness, or stability.'
);

SELECT
    concept_name,
    formal_role,
    systems_modeling_role,
    review_warning
FROM limit_assumption_registry
ORDER BY assumption_key;

This workflow turns mathematical assumptions into reviewable records. The model does not merely use limits; it documents which limiting ideas are being invoked and what warnings apply.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It supports article-level folders for calculus-based systems modeling, including epsilon-delta examples, sequential limit tests, convergence-order workflows, central-difference and Richardson extrapolation checks, roundoff review, invariant-set checks, typed approximation records, structured concept registries, reproducible notebooks, documentation, generated outputs, and advanced mathematical audit reports.

Back to top ↑

Interpretive Limits and Responsible Use

Limits give calculus rigor, but they do not automatically validate a systems model. A limit statement can be mathematically correct and still be irrelevant to the system if the model domain is wrong, the data are insufficient, the convergence mode is inappropriate, or the interpretation exceeds the assumptions.

Several risks are common. A modeler may assume continuity where the system has discontinuities. A numerical analyst may report convergence at sampled points while missing boundary failure. A simulation may appear stable over a finite time horizon but diverge later. A derivative may be estimated from noisy data even though local smoothness is unsupported. A limiting equilibrium may be mathematically stable but practically unreachable.

Responsible use requires explicit statements about domain, topology or metric, convergence mode, approximation method, error behavior, and empirical scope. Limits are not a substitute for modeling judgment. They are a discipline for making that judgment precise.

Back to top ↑

Related Articles

• Calculus for Systems Modeling
• What Is Calculus for Systems Modeling?
• Functions, Variables, and Mathematical Representation
• Domains, Ranges, and the Structure of Functional Models
• Infinity, Infinitesimals, and the Historical Problem of Change
• Continuity, Discontinuity, and Structural Breaks
• Differentiability and Local Behavior
• Mathematical Modeling
• Systems Modeling
• 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.
• OpenStax (2016a) Calculus Volume 1. Houston, TX: OpenStax, Rice University.
• 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.
• Ascher, U.M. and Greif, C. (2011) A First Course in Numerical Methods. Philadelphia, PA: Society for Industrial and Applied Mathematics.

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.
• Ascher, U.M. and Greif, C. (2011) A First Course in Numerical Methods. Philadelphia, PA: Society for Industrial and Applied Mathematics.
• Courant, R. and John, F. (1999) Introduction to Calculus and Analysis, Volume I. Berlin: 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.
• Rudin, W. (1976) Principles of Mathematical Analysis. 3rd edn. New York: McGraw-Hill.
• Spivak, M. (2008) Calculus. 4th edn. Houston, TX: Publish or Perish.
• Strogatz, S.H. (2015) Nonlinear Dynamics and Chaos: With Applications to Physics, Biology, Chemistry, and Engineering. 2nd edn. Boulder, CO: Westview Press.

Back to top ↑