Discrete Models and Recurrence Relations: How Mathematical Models Represent Stepwise Change

Last Updated June 14, 2026

Discrete models and recurrence relations describe systems that change in steps rather than continuously. Instead of asking how a state changes at every instant, they define how one state follows from a previous state: next population from current population, next balance from current deposits, next inventory from current stock, next generation from current survival, or next risk level from current conditions.

A recurrence relation is an update rule. It tells the model how to move from one step to the next. The step may represent a day, year, generation, production cycle, policy round, accounting period, iteration, decision stage, or computational update. This makes recurrence relations central to simulation, forecasting, algorithms, finance, operations, ecology, epidemiology, and complex systems.

Discrete models do not simply approximate continuous models. Sometimes the system itself is naturally discrete. Populations may reproduce in generations. Inventory may be counted in batches. Decisions may occur in budget cycles. Algorithms advance through iterations. A recurrence relation is useful when the modeled process is best understood as stepwise change.

Discrete modeling is powerful because it makes iteration explicit. It can represent state updates, thresholds, switching rules, population generations, inventory cycles, Markov transitions, algorithmic processes, and simulations that unfold one step at a time. It can also mislead if time steps, update order, rounding, aggregation, or transition assumptions are poorly chosen. A recurrence relation is simple to write, but its behavior can be surprisingly complex.

Why Discrete Models Matter

Discrete models matter because many systems change by identifiable steps. A budget updates each fiscal year. A population changes each generation. An algorithm updates after each iteration. A disease model may update daily counts. An inventory system updates after deliveries and sales. A policy model may update after each decision round.

In these cases, continuous-time modeling may not be the most natural representation. The model does not need to describe every instant. It needs to describe how the system moves from one step to the next.

A discrete model can be transparent and computationally practical. It can also reveal behavior that is not obvious from the update rule alone: convergence, oscillation, overshoot, collapse, lock-in, and threshold effects.

Back to top ↑

What a Discrete Model Is

A discrete model represents a system through values defined at separated points, categories, states, or steps. The index may be time, iteration number, generation, spatial cell, network node, or decision stage. In this article, the main focus is discrete-time modeling.

The index \(t\) usually represents a step number. It may correspond to a calendar interval, but it does not have to. In an algorithm, \(t\) may be iteration count. In a population model, it may be generation count. In a policy model, it may be decision stage.

Discrete models can be deterministic or stochastic, linear or nonlinear, scalar or vector-valued, simple or high-dimensional. Their common feature is stepwise representation.

Back to top ↑

What a Recurrence Relation Is

A recurrence relation defines a term in a sequence using earlier terms. In modeling, it defines the next state of a system from its current or previous states.

A recurrence may depend on multiple previous states:

Recurrence relations are common because they are easy to implement computationally. A loop in code often directly mirrors the mathematical update rule.

A recurrence relation should be interpreted as a claim about stepwise mechanism. It says what the model believes is sufficient to compute the next state.

Back to top ↑

State Variables, Time Steps, and Update Rules

Discrete models depend on careful definition of state variables, time steps, and update rules. The state variable records the system’s condition. The time step defines when updates occur. The update rule defines how one state produces the next.

A common state-update form is:

Discrete models often appear straightforward because they can be written as simple loops. But step size, update order, and boundary rules can change results. These are modeling assumptions, not programming details alone.

Back to top ↑

Sequences and Difference Equations

A sequence is an ordered list of values. A recurrence relation defines the sequence by specifying how each term is produced. A difference equation describes change between steps.

A difference equation may define this stepwise change directly:

This can be rewritten as a recurrence:

Difference equations provide the discrete-time counterpart to differential equations. Differential equations describe instantaneous rates. Difference equations describe changes across finite steps.

Back to top ↑

Linear Recurrence Relations

Linear recurrence relations are among the simplest and most useful discrete models. A first-order linear recurrence has the form:

This form can represent growth, decay, adjustment, savings, inventory, and many baseline processes. If \(b=0\), the recurrence becomes:

A financial balance with interest and deposit is another common example:

Linear recurrences are useful because their behavior can often be analyzed directly. But linearity still needs justification. A constant update rule may be a good local approximation, but it may fail near thresholds, capacity limits, or regime changes.

Back to top ↑

Nonlinear Recurrence Relations

Nonlinear recurrence relations can produce complex behavior from simple update rules. The next state depends nonlinearly on the current state, which can create saturation, oscillation, sensitivity, multiple fixed points, or chaotic behavior.

A bounded resource recurrence may take the form:

Nonlinear recurrences are useful when system behavior is genuinely state-dependent. They also require careful sensitivity analysis because small changes in parameters or initial conditions may produce very different trajectories.

Back to top ↑

Thresholds, Switching Rules, and Piecewise Updates

Discrete models often include thresholds and switching rules. A policy activates when a risk score crosses a boundary. Inventory is reordered when stock falls below a threshold. A system changes regime when capacity is exceeded. A model may use one update rule in normal conditions and another under stress.

Piecewise recurrence rules are common in operational and policy models because real decisions often occur at thresholds. But thresholds must be documented. A threshold can be physical, administrative, legal, ethical, empirical, or arbitrary.

Thresholds can make models more realistic, but they can also create artificial discontinuities. Sensitivity to threshold location should be tested, especially when decisions depend on crossing the boundary.

Back to top ↑

Stability, Fixed Points, and Long-Run Behavior

Discrete models often ask whether repeated updates converge, diverge, oscillate, or settle into more complex patterns. A fixed point is a state that reproduces itself under the update rule.

For a first-order recurrence \(x_{t+1}=f(x_t)\), stability depends on what happens when the system is slightly perturbed around the fixed point. A common local stability condition is:

Long-run behavior is not always the main concern. In policy, engineering, health, and operations, the path may matter more than the eventual fixed point. But fixed-point and stability analysis can still reveal whether the update rule is plausible.

Back to top ↑

Discrete Models Versus Continuous Models

Discrete models and continuous models represent time differently. A continuous model describes change at every instant. A discrete model describes change across steps. Neither is automatically superior. The right choice depends on the system, data, purpose, scale, and interpretation.

Discrete models can approximate continuous models, and continuous models can be discretized for computation. But approximation is not the same as representation. A modeler should explain whether discreteness reflects the system, the data, the computation, or a simplifying assumption.

Back to top ↑

Simulation and Computational Iteration

Discrete models are closely connected to simulation because recurrence relations naturally become loops. Each step uses the current state to compute the next state. This makes discrete models useful for scenario analysis, sensitivity analysis, forecasting, and exploratory modeling.

Computational iteration should be reviewed as part of model design. A recurrence rule may be mathematically clear, but implementation choices can still affect results.

Discrete simulation should be reproducible. That means saving scenario inputs, model version, outputs, random seeds when relevant, and diagnostics that show not only final results but also the trajectory.

Back to top ↑

Mathematical Lens: Recurrence as State Transition

A recurrence relation can be viewed as a state transition map:

With inputs and parameters, the transition becomes:

Outputs may be generated from the state:

Repeated application of the update rule produces a trajectory:

This lens shows that recurrence relations are not merely formulas. They define a transition system. The model’s behavior depends on the state space, update map, initial condition, inputs, parameters, constraints, and number of iterations.

Back to top ↑

Example: Discrete Resource Model

Consider a resource system updated once per period. Storage \(S_t\) changes through inflow \(I_t\), demand \(D_t\), and loss rate \(\lambda\). The recurrence relation is:

If shortage changes future demand, demand can become a state variable:

The model state becomes:

This example shows how a recurrence relation evolves with model purpose. A simple recurrence may be adequate for a teaching model or baseline scenario. Decision support may require additional state variables, thresholds, uncertainty, and validation.

Back to top ↑

Calibration, Validation, Sensitivity, and Uncertainty

Discrete models require validation because recurrence rules can generate long trajectories from compact assumptions. Small errors in update rules, parameters, step size, or initial conditions can grow across iterations.

Validation should examine the whole trajectory, not only the final state. A recurrence can match an endpoint while producing unrealistic intermediate behavior. It can also fit short-run data while failing under longer horizons, thresholds, or interventions.

Back to top ↑

Ethical Stakes of Discrete Modeling

Discrete models can shape decisions about resources, health, infrastructure, finance, policy, and risk. Their ethical stakes arise because stepwise assumptions can determine who is counted, when action occurs, when thresholds are crossed, and how future conditions are projected.

Responsible discrete modeling makes the step structure visible. It states what one step means, what happens inside each step, how thresholds are chosen, and how uncertainty grows through iteration.

Back to top ↑

Python Workflow: Recurrence Simulation and Stepwise Diagnostics

The Python workflow below simulates a discrete resource model with storage, demand, shortage, capacity, and optional adaptive demand. It exports recurrence trajectories, scenario summaries, and a model audit card.

# discrete_models_recurrence_relations_workflow.py
# Dependency-light workflow for recurrence simulation and stepwise diagnostics.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
from statistics import mean


ARTICLE_ROOT = Path(__file__).resolve().parents[1]
OUTPUTS = ARTICLE_ROOT / "outputs"
TABLES = OUTPUTS / "tables"
JSON_DIR = OUTPUTS / "json"


@dataclass(frozen=True)
class RecurrenceScenario:
    name: str
    initial_storage: float
    initial_demand: float
    capacity: float
    inflow: float
    loss_rate: float
    demand_response: float
    periods: int
    adaptive_demand: bool


@dataclass(frozen=True)
class RecurrenceRecord:
    key: str
    recurrence_type: str
    expression: str
    state_variable: str
    interpretation: str
    review_question: str
    status: str


def recurrence_register() -> list[RecurrenceRecord]:
    return [
        RecurrenceRecord(
            key="storage_update",
            recurrence_type="bounded_first_order",
            expression="S[t+1] = min(K, max(0, S[t] + I[t] - D[t] - lambda*S[t]))",
            state_variable="storage",
            interpretation="Storage updates through inflow, demand, and proportional loss.",
            review_question="Are boundary events reported rather than hidden by clipping?",
            status="active",
        ),
        RecurrenceRecord(
            key="demand_update",
            recurrence_type="adaptive_state",
            expression="D[t+1] = max(0, D[t] - alpha*Q[t])",
            state_variable="demand",
            interpretation="Demand adapts after shortage.",
            review_question="Is demand truly adaptive or should it be treated as external input?",
            status="review",
        ),
        RecurrenceRecord(
            key="shortage_diagnostic",
            recurrence_type="derived_output",
            expression="Q[t] = max(0, -raw_next_storage)",
            state_variable="shortage",
            interpretation="Shortage is derived from infeasible raw storage.",
            review_question="Is shortage accumulated, reported, or clipped away?",
            status="review",
        ),
    ]


def validate_scenario(scenario: RecurrenceScenario) -> None:
    if scenario.initial_storage < 0:
        raise ValueError("initial_storage must be nonnegative.")
    if scenario.capacity <= 0:
        raise ValueError("capacity must be positive.")
    if scenario.initial_storage > scenario.capacity:
        raise ValueError("initial_storage cannot exceed capacity.")
    if scenario.initial_demand < 0:
        raise ValueError("initial_demand must be nonnegative.")
    if scenario.inflow < 0:
        raise ValueError("inflow must be nonnegative.")
    if scenario.loss_rate < 0:
        raise ValueError("loss_rate must be nonnegative.")
    if scenario.demand_response < 0:
        raise ValueError("demand_response must be nonnegative.")
    if scenario.periods < 1:
        raise ValueError("periods must be at least 1.")


def simulate_recurrence(scenario: RecurrenceScenario) -> list[dict[str, object]]:
    validate_scenario(scenario)

    storage = scenario.initial_storage
    demand = scenario.initial_demand
    rows: list[dict[str, object]] = []

    for period in range(scenario.periods + 1):
        raw_next_storage = storage + scenario.inflow - demand - scenario.loss_rate * storage
        shortage = max(0.0, -raw_next_storage)
        overflow = max(0.0, raw_next_storage - scenario.capacity)
        next_storage = min(scenario.capacity, max(0.0, raw_next_storage))

        rows.append({
            "scenario": scenario.name,
            "period": period,
            "storage": round(storage, 8),
            "demand": round(demand, 8),
            "raw_next_storage": round(raw_next_storage, 8),
            "next_storage": round(next_storage, 8),
            "shortage": round(shortage, 8),
            "overflow": round(overflow, 8),
            "adaptive_demand": scenario.adaptive_demand,
            "domain_valid": 0.0 <= next_storage <= scenario.capacity,
        })

        if scenario.adaptive_demand:
            demand = max(0.0, demand - scenario.demand_response * shortage)

        storage = next_storage

    return rows


def summarize(rows: list[dict[str, object]]) -> dict[str, object]:
    if not rows:
        raise ValueError("Cannot summarize empty rows.")

    storage = [float(row["storage"]) for row in rows]
    demand = [float(row["demand"]) for row in rows]
    shortages = [float(row["shortage"]) for row in rows]
    overflows = [float(row["overflow"]) for row in rows]
    domain_flags = [bool(row["domain_valid"]) for row in rows]

    return {
        "scenario": str(rows[0]["scenario"]),
        "final_storage": round(storage[-1], 8),
        "mean_storage": round(mean(storage), 8),
        "final_demand": round(demand[-1], 8),
        "shortage_periods": sum(1 for value in shortages if value > 0),
        "overflow_periods": sum(1 for value in overflows if value > 0),
        "domain_violations": sum(1 for value in domain_flags if not value),
        "total_shortage": round(sum(shortages), 8),
        "total_overflow": round(sum(overflows), 8),
    }


def recurrence_risk_score(record: RecurrenceRecord) -> float:
    score = {"active": 1.0, "review": 5.0, "revise": 8.0, "archive": 2.0}.get(
        record.status.lower(),
        4.0,
    )
    text = f"{record.recurrence_type} {record.expression} {record.review_question}".lower()
    for term in ["boundary", "adaptive", "shortage", "clipping", "threshold", "derived"]:
        if term in text:
            score += 1.0
    return round(score, 3)


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        raise ValueError(f"No rows supplied for {path}")
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", encoding="utf-8") as handle:
        json.dump(payload, handle, indent=2, sort_keys=True)


def main() -> None:
    scenarios = [
        RecurrenceScenario("baseline", 80.0, 7.0, 100.0, 6.0, 0.015, 0.0, 60, False),
        RecurrenceScenario("high_demand", 80.0, 10.0, 100.0, 6.0, 0.015, 0.0, 60, False),
        RecurrenceScenario("adaptive_demand", 45.0, 10.0, 80.0, 4.0, 0.020, 0.20, 60, True),
        RecurrenceScenario("tight_capacity", 70.0, 7.0, 75.0, 8.0, 0.015, 0.0, 60, False),
    ]

    all_rows: list[dict[str, object]] = []
    summary_rows: list[dict[str, object]] = []

    for scenario in scenarios:
        rows = simulate_recurrence(scenario)
        all_rows.extend(rows)
        summary_rows.append(summarize(rows))

    register_rows = [
        {**asdict(record), "recurrence_risk_score": recurrence_risk_score(record)}
        for record in recurrence_register()
    ]

    write_csv(TABLES / "recurrence_timeseries.csv", all_rows)
    write_csv(TABLES / "recurrence_summary.csv", summary_rows)
    write_csv(TABLES / "recurrence_model_register.csv", register_rows)

    write_json(JSON_DIR / "recurrence_model_audit_card.json", {
        "article": "Discrete Models and Recurrence Relations",
        "recurrence_register": register_rows,
        "scenario_summaries": summary_rows,
        "audit_checks": [
            "step meaning is documented",
            "update order is explicit",
            "boundary events are reported",
            "recurrence trajectories are preserved",
            "static endpoints are not substituted for dynamic behavior",
        ],
    })

    print("Discrete models and recurrence relations workflow complete.")
    print(f"Wrote outputs to {OUTPUTS}")


if __name__ == "__main__":
    main()

This workflow makes boundary events and adaptive demand visible rather than hiding them inside the recurrence update. It preserves trajectories so the model can be reviewed as a sequence of states, not only as a final value.

Back to top ↑

R Workflow: Recurrence Review and Iteration Diagnostics

The R workflow below reviews generated recurrence outputs, classifies stress behavior, and creates a stepwise trajectory plot.

# discrete_models_recurrence_relations_review.R
# Base R workflow for recurrence review and iteration diagnostics.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")
dir.create(tables_dir, recursive = TRUE, showWarnings = FALSE)
dir.create(figures_dir, recursive = TRUE, showWarnings = FALSE)

timeseries_path <- file.path(tables_dir, "recurrence_timeseries.csv")
summary_path <- file.path(tables_dir, "recurrence_summary.csv")
register_path <- file.path(tables_dir, "recurrence_model_register.csv")

if (!file.exists(timeseries_path) || !file.exists(summary_path)) {
  stop("Missing recurrence outputs. Run the Python workflow first.")
}

timeseries <- read.csv(timeseries_path, stringsAsFactors = FALSE)
summary_data <- read.csv(summary_path, stringsAsFactors = FALSE)

summary_data$recurrence_review <- ifelse(
  summary_data$domain_violations > 0,
  "domain violation detected",
  ifelse(
    summary_data$shortage_periods > 0 | summary_data$overflow_periods > 0,
    "boundary or stress behavior active",
    "stepwise trajectory stable under scenario"
  )
)

write.csv(
  summary_data,
  file.path(tables_dir, "r_recurrence_review_summary.csv"),
  row.names = FALSE
)

if (file.exists(register_path)) {
  register <- read.csv(register_path, stringsAsFactors = FALSE)

  register$priority <- ifelse(
    register$recurrence_risk_score >= 8,
    "high",
    ifelse(register$recurrence_risk_score >= 6, "medium", "low")
  )

  write.csv(
    register,
    file.path(tables_dir, "r_recurrence_review_queue.csv"),
    row.names = FALSE
  )
}

png(file.path(figures_dir, "r_recurrence_storage_trajectories.png"), width = 1100, height = 720)

scenario_names <- unique(timeseries$scenario)
plot(
  NULL,
  xlim = range(timeseries$period),
  ylim = range(timeseries$storage),
  xlab = "Period",
  ylab = "Storage",
  main = "Discrete Recurrence Storage Trajectories"
)

for (scenario in scenario_names) {
  rows <- timeseries[timeseries$scenario == scenario, ]
  lines(rows$period, rows$storage, lwd = 2, type = "s")
}

legend("bottomright", legend = scenario_names, lwd = 2, cex = 0.85)
grid()
dev.off()

print(summary_data)

The R layer emphasizes iteration diagnostics. It helps prevent recurrence models from being evaluated only by endpoints when stepwise stress behavior, boundary events, and update timing matter.

Back to top ↑

Haskell Workflow: Typed Recurrence Records

Haskell is useful for this article because recurrence components should not collapse into a single informal category. State variables, update rules, initial conditions, boundaries, diagnostics, and numerical settings play different roles.

{-# OPTIONS_GHC -Wall #-}

module Main where

data RecurrenceComponent
  = StateVariable
  | UpdateRule
  | InitialCondition
  | BoundaryRule
  | Parameter
  | OutputDiagnostic
  | StepDefinition
  deriving (Eq, Show)

data ReviewStatus
  = Active
  | RequiresReview
  | RequiresValidation
  | RequiresSensitivityTest
  | Revise
  deriving (Eq, Show)

data RecurrenceRecord = RecurrenceRecord
  { key :: String
  , component :: RecurrenceComponent
  , expression :: String
  , interpretation :: String
  , domainOrStep :: String
  , status :: ReviewStatus
  } deriving (Eq, Show)

recurrenceRegister :: [RecurrenceRecord]
recurrenceRegister =
  [ RecurrenceRecord
      "storage"
      StateVariable
      "S_t"
      "Current resource storage at period t."
      "0 <= S_t <= K"
      Active
  , RecurrenceRecord
      "storage_update"
      UpdateRule
      "S_{t+1} = min(K, max(0, S_t + I_t - D_t - lambda*S_t))"
      "Storage updates through inflow, demand, and proportional loss."
      "one period"
      RequiresReview
  , RecurrenceRecord
      "initial_storage"
      InitialCondition
      "S_0"
      "Starting storage."
      "0 <= S_0 <= K"
      RequiresValidation
  , RecurrenceRecord
      "shortage"
      OutputDiagnostic
      "Q_t = max(0, -raw_next_storage)"
      "Unmet demand before boundary clipping."
      "reported each period"
      RequiresSensitivityTest
  ]

needsReview :: RecurrenceRecord -> Bool
needsReview item =
  case status item of
    Active -> False
    _ -> True

main :: IO ()
main = do
  putStrLn "Typed recurrence records:"
  mapM_ print recurrenceRegister

  putStrLn "\nRecurrence records requiring review:"
  mapM_ print (filter needsReview recurrenceRegister)

This typed layer supports model governance by making step definition, update logic, boundary handling, and output diagnostics explicit before recurrence results are trusted.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It contains article-specific code, data, documentation, notebooks, schemas, and generated outputs for recurrence model registers, discrete-time simulation, stepwise trajectory diagnostics, boundary-event review, typed Haskell recurrence records, validation planning, and reproducible engineering/statistical workflows.

Back to top ↑

A Practical Method for Discrete Model Design

Discrete model design should begin with the meaning of the step. A recurrence relation is not only a formula; it is a structured statement about how a system moves through a sequence of states.

This method helps prevent recurrence relations from becoming unexamined loops. It connects discrete modeling to purpose, state, timing, update logic, validation, and responsible interpretation.

Back to top ↑

Common Pitfalls

Discrete models can fail in ways that are easy to miss because the update rule may look simple. Many failures come from treating implementation details as if they were not modeling assumptions.

• Unclear step meaning: using \(t\) without specifying whether it means day, year, generation, iteration, or decision round.
• Update-order error: changing model behavior by applying updates in the wrong sequence.
• Boundary clipping without reporting: forcing states into valid ranges while hiding shortage, overflow, or failure events.
• Coarse time step: using steps too large to represent the process being modeled.
• Rounding artifacts: rounding too early and creating artificial stability or instability.
• Static endpoint bias: evaluating only the final value instead of the full trajectory.
• Hidden memory omission: leaving out lagged variables, backlog, or cumulative exposure.
• Threshold fragility: allowing decisions to depend heavily on uncertain threshold values.
• Linear default bias: assuming a linear update when feedback or saturation matters.
• False forecast confidence: treating iterated scenarios as guaranteed futures.

These pitfalls can be reduced through state registers, recurrence registers, boundary-event reporting, step-size review, update-order documentation, trajectory diagnostics, sensitivity testing, and uncertainty communication.

Back to top ↑

Conclusion: Discrete Models Make Steps Explicit

Discrete models and recurrence relations make stepwise change explicit. They describe how one state follows from another, how iteration produces trajectories, and how update rules shape behavior over time.

The strength of discrete modeling is its clarity about sequence. It can represent generations, cycles, reporting intervals, policy rounds, simulations, algorithms, inventory updates, financial periods, and decision stages. It can also reveal convergence, oscillation, thresholds, boundary events, and long-run behavior that may not be obvious from the recurrence relation alone.

But recurrence relations require discipline. The modeler must define the step, state variables, initial conditions, update order, constraints, parameters, and outputs. They must preserve trajectories, report boundary events, test sensitivity, and avoid treating conditional scenarios as inevitable futures.

A recurrence relation is a structured claim about how a system moves from now to next. Used responsibly, it helps modelers reason about systems that change one step at a time.

Back to top ↑

Related Articles

• What Is Mathematical Modeling?
• The Modeling Process: From World to Formal Representation
• State Variables and System Representation
• Algebraic Models and Static Relationships
• Differential Equations and Dynamic Models
• Probabilistic and Stochastic Models
• Optimization Models and Objective Functions
• Simulation and Computational Modeling
• Monte Carlo Simulation and Uncertainty Propagation
• Sensitivity Analysis and Robustness

Back to top ↑

Further Reading

• Elaydi, S. (2005) An Introduction to Difference Equations. 3rd edn. New York: Springer.
• Kelley, W.G. and Peterson, A.C. (2001) Difference Equations: An Introduction with Applications. 2nd edn. San Diego: Academic Press.
• Allman, E.S. and Rhodes, J.A. (2004) Mathematical Models in Biology: An Introduction. Cambridge: Cambridge University Press.
• Otto, S.P. and Day, T. (2007) A Biologist’s Guide to Mathematical Modeling in Ecology and Evolution. Princeton: Princeton University Press.
• Strogatz, S.H. (2015) Nonlinear Dynamics and Chaos: With Applications to Physics, Biology, Chemistry, and Engineering. 2nd edn. Boulder, CO: Westview Press.
• Sterman, J.D. (2000) Business Dynamics: Systems Thinking and Modeling for a Complex World. Boston: Irwin/McGraw-Hill.
• Grinstead, C.M. and Snell, J.L. (1997) Introduction to Probability. Providence, RI: American Mathematical Society. Available at: https://math.dartmouth.edu/~prob/prob/prob.pdf
• Higham, N.J. (2002) Accuracy and Stability of Numerical Algorithms. 2nd edn. Philadelphia: Society for Industrial and Applied Mathematics. Available at: https://doi.org/10.1137/1.9780898718027
• Garfunkel, S. and Montgomery, M. (eds.) (2019) GAIMME: Guidelines for Assessment and Instruction in Mathematical Modeling Education. 2nd edn. Philadelphia: Society for Industrial and Applied Mathematics. Available at: https://www.siam.org/publications/reports/guidelines-for-assessment-and-instruction-in-mathematical-modeling-education/
• Oberkampf, W.L. and Roy, C.J. (2010) Verification and Validation in Scientific Computing. Cambridge: Cambridge University Press. Available at: https://www.cambridge.org/core/books/verification-and-validation-in-scientific-computing/05CA1F8F3CCB5AE5445FDF55239A0183

Back to top ↑

References

• Allman, E.S. and Rhodes, J.A. (2004) Mathematical Models in Biology: An Introduction. Cambridge: Cambridge University Press.
• Elaydi, S. (2005) An Introduction to Difference Equations. 3rd edn. New York: Springer.
• Garfunkel, S. and Montgomery, M. (eds.) (2019) GAIMME: Guidelines for Assessment and Instruction in Mathematical Modeling Education. 2nd edn. Philadelphia: Society for Industrial and Applied Mathematics. Available at: https://epubs.siam.org/doi/book/10.1137/1.9781611975741
• Grinstead, C.M. and Snell, J.L. (1997) Introduction to Probability. Providence, RI: American Mathematical Society. Available at: https://math.dartmouth.edu/~prob/prob/prob.pdf
• Higham, N.J. (2002) Accuracy and Stability of Numerical Algorithms. 2nd edn. Philadelphia: Society for Industrial and Applied Mathematics. Available at: https://doi.org/10.1137/1.9780898718027
• Kelley, W.G. and Peterson, A.C. (2001) Difference Equations: An Introduction with Applications. 2nd edn. San Diego: Academic Press.
• Oberkampf, W.L. and Roy, C.J. (2010) Verification and Validation in Scientific Computing. Cambridge: Cambridge University Press. Available at: https://www.cambridge.org/core/books/verification-and-validation-in-scientific-computing/05CA1F8F3CCB5AE5445FDF55239A0183
• Otto, S.P. and Day, T. (2007) A Biologist’s Guide to Mathematical Modeling in Ecology and Evolution. Princeton: Princeton University Press.
• Sterman, J.D. (2000) Business Dynamics: Systems Thinking and Modeling for a Complex World. Boston: Irwin/McGraw-Hill.
• 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 ↑