State Variables and System Representation: How Mathematical Models Track Change

Last Updated June 12, 2026

State variables and system representation determine how a mathematical model describes what a system is, how it changes, and what information is needed to predict or interpret its future behavior. A state variable captures a quantity that summarizes a system’s condition at a given time. System representation organizes those quantities into a formal structure.

In a resource model, storage may be a state variable. In an epidemic model, the number of susceptible, infected, and recovered people may be state variables. In a mechanical model, position and velocity may define the state. In a policy model, institutional capacity, backlog, funding, exposure, or risk may function as state variables. The choice of state determines what the model remembers, what it can update, and what it can explain.

A model’s representation is not only its equation. It may be a state-space model, stock-and-flow diagram, matrix system, network, agent state table, simulation object, graph, probability distribution, or computational workflow. Good representation makes the model’s state, inputs, outputs, parameters, constraints, and update logic visible enough to analyze, validate, revise, and communicate.

State is a modeling commitment. It says which aspects of a system are necessary for describing its condition and projecting its next behavior. If the chosen state variables omit memory, delay, backlog, depletion, exposure, hidden capacity, or feedback, the model may behave as if those features do not exist. If the representation is unclear, users may not know what the model is actually tracking.

Why State Variables Matter

State variables matter because many systems cannot be understood from inputs alone. A system’s next behavior often depends on its current condition. A reservoir’s future shortage depends on current storage. A disease system’s future spread depends on current infection states. An economy’s future output depends partly on current capital, labor, demand, and expectations. A queue’s future delay depends on current backlog.

A state variable gives the model memory. It records something that persists through time and influences future behavior. Without state, a model may become a static mapping from input to output. With state, a model can represent accumulation, depletion, delay, inertia, recovery, degradation, adaptation, and path dependence.

State selection is therefore a central design decision. If the state is too thin, the model cannot represent important dynamics. If the state is too large, the model may become difficult to estimate, validate, communicate, or compute. Good state design balances adequacy, simplicity, evidence, and purpose.

Back to top ↑

What a State Variable Is

A state variable is a quantity that describes the condition of a system at a particular time and helps determine how the system evolves. In dynamic modeling, the state is often the information needed to update the system from one moment to the next.

Many models use a vector of state variables rather than a single quantity:

A state variable is not merely any variable. It is a variable with memory and updating significance. It helps define where the system is now and what can happen next.

Back to top ↑

State Variables, Inputs, Outputs, and Parameters

State variables should be distinguished from inputs, outputs, parameters, and decision variables. These categories can overlap in some models, but confusing them can distort interpretation.

The distinction matters because each component has a different modeling responsibility. A state variable is updated. An input drives change. A parameter shapes change. An output communicates change. A decision variable selects action. A latent variable requires inference.

Good representation makes these roles explicit. If a model does not distinguish state, input, output, and parameter, users may not know what the model is tracking, what it controls, and what it merely reports.

Back to top ↑

What System Representation Means

System representation is the formal way a model organizes its variables, relationships, boundaries, and update logic. A system can be represented as equations, matrices, stock-and-flow diagrams, networks, state machines, agent state tables, probability models, optimization problems, or simulation objects.

Representation determines what is easy to see. A stock-and-flow diagram makes accumulation visible. A matrix system makes linear dynamics and coupling visible. A network representation makes connections visible. A state-space representation makes control and observation visible. A simulation object makes computational process visible.

A model may combine representations. An epidemic model can use compartments, equations, matrices, networks, and simulation at the same time. The important point is to document how each representation relates to the others.

Back to top ↑

State-Space Representation

State-space representation is a common way to describe dynamic systems. It separates the state update equation from the output or observation equation. This distinction is useful because the system’s internal condition may not be the same as what is observed.

For a linear state-space model, the structure is often written as:

State-space representation is especially useful when the model must support forecasting, filtering, control, monitoring, or decision support. It clarifies the difference between what the system is, what affects it, and what can be observed.

Back to top ↑

Stocks, Flows, Memory, and Accumulation

Many state variables are stocks. A stock is an accumulated quantity that changes through inflows and outflows. Storage, population, capital, debt, biomass, backlog, infrastructure condition, and cumulative exposure can all be modeled as stocks.

Stocks give systems memory. A shortage today may reflect past inflows, past demand, past losses, and past policy choices. A backlog today may reflect earlier capacity limits. A health burden today may reflect cumulative exposure. Accumulation makes history visible.

A model that omits stock variables may miss the behavior caused by accumulation. This is a common reason policy models underestimate delay, inertia, path dependence, or recovery time.

Back to top ↑

Discrete and Continuous State

State variables may be continuous, discrete, categorical, binary, ordinal, or hybrid. The representation should match the system and purpose. Temperature, storage, and concentration are often continuous. Disease status, machine status, eligibility, and workflow stage are often discrete or categorical.

Hybrid systems are common. A resource model may have continuous storage and discrete policy regimes. An infrastructure model may have continuous degradation and categorical failure states. A public health model may have count states, probability states, and policy status. The representation should make this mixture visible.

Back to top ↑

Observability, Hidden State, and Measurement

Not every state variable is directly observed. A model may infer hidden state from measurements. True infection prevalence, soil moisture, structural fatigue, public trust, latent demand, or organizational capacity may not be directly visible. The model must connect hidden state to observations through a measurement relationship.

Observability asks whether the state can be inferred from available measurements. If important state variables are hidden and weakly measured, the model may be underidentified or unstable.

Measurement is part of representation. A model that treats noisy, delayed, or proxy observations as true state may overstate confidence and misrepresent system behavior.

Back to top ↑

Feedback, Control, and State Updates

State variables are central to feedback and control. Feedback occurs when the current state or output influences future inputs, decisions, or system behavior. Control occurs when actions are chosen to move the system toward a desired condition while respecting constraints.

Feedback can stabilize a system, but it can also produce oscillation, overshoot, lock-in, or policy resistance. A representation that omits state feedback may miss the most important behavior of the system.

Back to top ↑

Network, Agent, and Multi-Unit State

Some systems require state variables for many connected units. In a network model, each node may have its own state. In an agent-based model, each agent may have attributes, memory, rules, and local environment. In spatial models, each region or grid cell may have state.

Multi-unit state makes heterogeneity visible. It allows the model to show differences across people, locations, institutions, nodes, or agents. It can reveal cascading failure, localized vulnerability, contagion, clustering, and unequal outcomes.

The choice between aggregate and distributed state is partly technical and partly ethical. Aggregation can simplify, but it can also hide who is affected, where failure occurs, and how risks propagate.

Back to top ↑

Choosing a System Representation

System representation should follow model purpose, evidence, scale, and use context. A model built for explanation may use transparent state variables and simple updates. A model built for control may require state-space representation. A model built for equity review may need disaggregated state. A model built for network resilience must represent connections.

There is no universal best representation. The right representation is one that is adequate for the question, supported by evidence, interpretable to users, testable against data, and honest about what it omits.

Back to top ↑

Mathematical Lens: State as Sufficient Information

In many dynamic models, the state is designed to contain enough information to determine the next state, given inputs and parameters. This idea can be written as:

If the model also has observations, it may include an output equation:

In continuous time, the state may evolve according to a differential equation:

In stochastic systems, the next state may be probabilistic:

This lens clarifies why state selection matters. If the current state is missing important information, the update equation may need hidden memory, lagged variables, additional state variables, or a different representation.

Back to top ↑

Example: State Variables in a Resource System

Consider a resource system with storage, inflow, demand, loss, shortage, and capacity. A minimal model might use only storage \(S_t\) as the state:

But if shortage affects future demand, then demand may need to become part of the state:

If infrastructure condition affects losses, then condition may also become state:

The example shows that state representation grows as the model’s purpose changes. A simple state may be enough for basic explanation. A richer state may be needed for feedback, control, equity review, resilience, or long-term planning.

Back to top ↑

Validation, Sensitivity, and State Adequacy

Validation should ask whether the chosen state variables are adequate for the model’s purpose. A model may match some outputs while using an inadequate state representation. It may fit historical observations but fail under intervention because it omitted feedback or hidden state.

State adequacy depends on use. A communication model may use fewer state variables to clarify a mechanism. A high-stakes decision-support model may need richer state, uncertainty, and measurement review. A control model must represent the state needed to choose safe action.

Back to top ↑

Ethical Stakes of State Representation

State representation has ethical consequences because it determines what the model remembers and what it forgets. A policy model that omits backlog may understate institutional strain. A health model that omits vulnerable subgroups may hide unequal risk. An infrastructure model that omits maintenance history may blame current failure on current demand rather than accumulated neglect.

Responsible modeling does not require representing everything. It requires honesty about what the state includes, what it omits, and how those choices affect interpretation, accountability, and use.

Back to top ↑

Python Workflow: State Register and System Representation Audit

The Python workflow below treats state variables as reviewable model objects. It compares storage-only, adaptive-demand, and condition-aware resource representations, then exports state registers, scenario summaries, and a representation audit card.

# state_variables_system_representation_workflow.py
# Dependency-light workflow for state-variable and system-representation review.

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 StateVariable:
    key: str
    state_type: str
    unit: str
    interpretation: str
    update_role: str
    observability: str
    review_question: str
    status: str


@dataclass(frozen=True)
class RepresentationScenario:
    name: str
    representation: str
    initial_storage: float
    initial_demand: float
    initial_condition: float
    capacity: float
    inflow: float
    loss_rate: float
    demand_response: float
    condition_decay: float
    periods: int


def validate_scenario(scenario: RepresentationScenario) -> 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 not 0 <= scenario.initial_condition <= 1:
        raise ValueError("initial_condition must be between 0 and 1.")
    if scenario.inflow < 0:
        raise ValueError("inflow must be nonnegative.")
    if not 0 <= scenario.loss_rate <= 1:
        raise ValueError("loss_rate must be between 0 and 1.")
    if scenario.periods < 1:
        raise ValueError("periods must be at least 1.")


def state_register() -> list[StateVariable]:
    return [
        StateVariable(
            key="storage",
            state_type="continuous_stock",
            unit="resource units",
            interpretation="Current stored resource.",
            update_role="Updated by inflow, demand, and loss.",
            observability="directly observed",
            review_question="Does storage remain within capacity and nonnegativity bounds?",
            status="active",
        ),
        StateVariable(
            key="demand",
            state_type="adaptive_state",
            unit="resource units per period",
            interpretation="Demand that can adapt after shortage.",
            update_role="Updated by shortage response logic.",
            observability="partially observed",
            review_question="Is demand truly stateful or should it be treated as external input?",
            status="review",
        ),
        StateVariable(
            key="infrastructure_condition",
            state_type="latent_condition",
            unit="dimensionless index",
            interpretation="Condition of infrastructure supporting storage and delivery.",
            update_role="Degrades under stress and affects effective loss.",
            observability="proxy observed",
            review_question="Is the condition index validated or only assumed?",
            status="review",
        ),
        StateVariable(
            key="shortage",
            state_type="derived_output",
            unit="resource units",
            interpretation="Unmet demand after storage update.",
            update_role="Derived from raw next-state balance.",
            observability="reported output",
            review_question="Is shortage a state, output, or accumulated backlog?",
            status="review",
        ),
    ]


def simulate(scenario: RepresentationScenario) -> list[dict[str, object]]:
    validate_scenario(scenario)

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

    for period in range(scenario.periods + 1):
        effective_loss_rate = scenario.loss_rate

        if scenario.representation == "condition_aware":
            effective_loss_rate = scenario.loss_rate * (1.0 + (1.0 - condition))

        losses = effective_loss_rate * storage
        raw_next_storage = storage + scenario.inflow - demand - losses
        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,
            "representation": scenario.representation,
            "period": period,
            "storage": round(storage, 8),
            "demand": round(demand, 8),
            "condition": round(condition, 8),
            "effective_loss_rate": round(effective_loss_rate, 8),
            "raw_next_storage": round(raw_next_storage, 8),
            "next_storage": round(next_storage, 8),
            "shortage": round(shortage, 8),
            "overflow": round(overflow, 8),
            "domain_valid": 0.0 <= next_storage <= scenario.capacity and 0.0 <= condition <= 1.0,
        })

        if scenario.representation in {"adaptive_demand", "condition_aware"}:
            demand = max(0.0, demand - scenario.demand_response * shortage)

        if scenario.representation == "condition_aware":
            stress = shortage + overflow
            condition = max(0.0, condition - scenario.condition_decay * stress)

        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]
    condition = [float(row["condition"]) 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"]),
        "representation": str(rows[0]["representation"]),
        "final_storage": round(storage[-1], 8),
        "mean_storage": round(mean(storage), 8),
        "final_demand": round(demand[-1], 8),
        "final_condition": round(condition[-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 state_risk_score(record: StateVariable) -> float:
    score = {"active": 1.0, "review": 5.0, "revise": 8.0, "archive": 2.0}.get(
        record.status.lower(),
        4.0,
    )
    text = f"{record.state_type} {record.observability} {record.review_question}".lower()
    for term in ["latent", "proxy", "partially", "backlog", "capacity", "hidden", "adaptive"]:
        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 = [
        RepresentationScenario("storage_only_baseline", "storage_only", 80.0, 7.0, 1.0, 100.0, 6.0, 0.015, 0.0, 0.0, 60),
        RepresentationScenario("adaptive_demand_stress", "adaptive_demand", 45.0, 8.0, 1.0, 80.0, 4.0, 0.020, 0.20, 0.0, 60),
        RepresentationScenario("condition_aware_stress", "condition_aware", 45.0, 8.0, 0.85, 80.0, 4.0, 0.020, 0.20, 0.002, 60),
    ]

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

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

    state_rows = [
        {**asdict(record), "state_risk_score": state_risk_score(record)}
        for record in state_register()
    ]

    write_csv(TABLES / "state_representation_timeseries.csv", all_rows)
    write_csv(TABLES / "state_representation_summary.csv", summary_rows)
    write_csv(TABLES / "state_variable_register.csv", state_rows)

    write_json(JSON_DIR / "state_representation_audit_card.json", {
        "article": "State Variables and System Representation",
        "state_register": state_rows,
        "scenario_summaries": summary_rows,
        "representation_review_questions": [
            "Does the state contain enough information to update the system?",
            "Which variables are state, input, output, parameter, or derived diagnostic?",
            "Are hidden or proxy states clearly documented?",
            "Does aggregation hide important state variation?",
            "Do conclusions change under alternative state representations?",
        ],
    })

    print("State variables and system representation workflow complete.")
    print(f"Wrote outputs to {OUTPUTS}")


if __name__ == "__main__":
    main()

This workflow demonstrates that changing the state representation changes model behavior. A storage-only model, an adaptive-demand model, and a condition-aware model may use similar data, but they remember different things and therefore reason differently.

Back to top ↑

R Workflow: State Diagnostics and Representation Review

The R workflow below reviews generated state summaries, classifies representation risk, and creates a diagnostic plot comparing shortage across alternative state choices.

# state_variables_system_representation_review.R
# Base R workflow for state diagnostics and representation review.

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)

summary_path <- file.path(tables_dir, "state_representation_summary.csv")
state_path <- file.path(tables_dir, "state_variable_register.csv")

if (!file.exists(summary_path)) {
  stop("Missing state_representation_summary.csv. Run the Python workflow first.")
}

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

summary_data$representation_review <- ifelse(
  summary_data$domain_violations > 0,
  "domain violation detected",
  ifelse(
    summary_data$shortage_periods > 0 | summary_data$overflow_periods > 0,
    "state representation activates stress behavior",
    "state representation stable under scenario"
  )
)

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

if (file.exists(state_path)) {
  states <- read.csv(state_path, stringsAsFactors = FALSE)

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

  write.csv(
    states,
    file.path(tables_dir, "r_state_review_queue.csv"),
    row.names = FALSE
  )
}

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

barplot(
  height = summary_data$total_shortage,
  names.arg = summary_data$representation,
  las = 2,
  ylab = "Total shortage",
  main = "Shortage Across State Representations"
)

grid()
dev.off()

print(summary_data)

The R layer helps compare state representations and identify when omitted state, hidden state, or adaptive state changes the model’s conclusions.

Back to top ↑

Haskell Workflow: Typed State Representations

Haskell is useful for this article because state variables, inputs, outputs, parameters, and derived diagnostics should not collapse into the same informal category. A typed layer makes those roles explicit.

{-# OPTIONS_GHC -Wall #-}

module Main where

data VariableRole
  = StateVariable
  | InputVariable
  | OutputVariable
  | Parameter
  | DerivedDiagnostic
  | LatentState
  deriving (Eq, Show)

data Observability
  = DirectlyObserved
  | PartiallyObserved
  | ProxyObserved
  | Hidden
  deriving (Eq, Show)

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

data VariableRecord = VariableRecord
  { key :: String
  , role :: VariableRole
  , unitLabel :: String
  , interpretation :: String
  , observability :: Observability
  , status :: ReviewStatus
  } deriving (Eq, Show)

stateRegister :: [VariableRecord]
stateRegister =
  [ VariableRecord
      "storage"
      StateVariable
      "resource units"
      "Current stored resource."
      DirectlyObserved
      Active
  , VariableRecord
      "demand"
      StateVariable
      "resource units per period"
      "Adaptive demand affected by shortage."
      PartiallyObserved
      RequiresReview
  , VariableRecord
      "infrastructure_condition"
      LatentState
      "dimensionless index"
      "Condition of infrastructure supporting storage and delivery."
      ProxyObserved
      RequiresValidation
  , VariableRecord
      "shortage"
      DerivedDiagnostic
      "resource units"
      "Unmet demand after update."
      DirectlyObserved
      RequiresSensitivityTest
  ]

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

main :: IO ()
main = do
  putStrLn "Typed state and representation records:"
  mapM_ print stateRegister

  putStrLn "\nRecords requiring representation review:"
  mapM_ print (filter needsReview stateRegister)

This typed layer supports repository governance by requiring every variable to identify its role, unit, interpretation, observability, and review status.

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 state-variable registers, state-space representations, storage-only and adaptive-state scenarios, condition-aware system models, typed Haskell state records, validation planning, and reproducible engineering/statistical workflows.

Back to top ↑

A Practical Method for State Representation Design

State representation design should be treated as a formal modeling step. The method below can be used before coding, during model review, or before publishing results.

This method helps prevent state variables from being selected only by convenience. It connects state representation to purpose, evidence, observability, validation, and responsibility.

Back to top ↑

Common Pitfalls

State representation errors often appear as poor forecasts, unstable simulations, misleading policy conclusions, or weak validation. Many begin with an inadequate account of what the system must remember.

• State-input confusion: treating a persistent system condition as an external input.
• Output-state confusion: reporting a derived output as if it were a directly modeled state.
• Memoryless modeling: omitting accumulated stocks, backlog, exposure, or depletion.
• Hidden-state overconfidence: inferring unobserved state without acknowledging uncertainty.
• Proxy-state substitution: treating an index or proxy as if it were the underlying condition.
• Over-aggregation: representing a system with one state when local variation drives behavior.
• State explosion: adding many state variables without data, validation, or interpretability.
• Unclear update logic: listing state variables without showing how they change.
• Observation mismatch: comparing model state to measured output without a measurement equation.
• Purpose mismatch: using a state representation suitable for explanation as if it were validated for control or decision support.

These pitfalls can be reduced through state registers, role tables, observation models, alternative state comparisons, domain checks, and explicit connection between representation and purpose.

Back to top ↑

Conclusion: State Defines What the Model Can Remember

State variables and system representation define what a mathematical model can remember, update, observe, control, and explain. A state variable is not just another symbol. It is a claim about what condition matters for future behavior.

The choice of state determines whether a model can represent accumulation, delay, path dependence, feedback, hidden condition, heterogeneity, and control. The choice of representation determines whether those relationships are visible, testable, and communicable.

Good modeling practice makes state explicit. It distinguishes state from input, output, parameter, decision variable, and diagnostic. It asks whether the state is observable, sufficient, valid, and appropriate for the model’s purpose. It also acknowledges what the chosen representation leaves outside.

A model cannot reason about what it does not represent. State design is therefore one of the central acts of mathematical modeling.

Back to top ↑

Related Articles

• What Is Mathematical Modeling?
• The Modeling Process: From World to Formal Representation
• Abstraction and Representation in Mathematical Models
• Assumptions, Simplification, and Model Design
• Model Boundaries, Scale, and Scope
• Variables, Parameters, and Constraints
• Functional Relationships and Mathematical Structure
• Equations, Inequalities, and Model Logic
• Dimensional Analysis, Units, and Scale
• Algebraic Models and Static Relationships
• Differential Equations and Dynamic Models
• Simulation and Computational Modeling

Back to top ↑

Further Reading

• Åström, K.J. and Murray, R.M. (2021) Feedback Systems: An Introduction for Scientists and Engineers. 2nd edn. Princeton: Princeton University Press. Available at: https://fbsbook.org/
• 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/
• COMAP (n.d.) Mathematical Modeling Handbook. Consortium for Mathematics and Its Applications. Available at: https://www.comap.com/membership/member-resources/item/mathematical-modeling-handbook
• Ogata, K. (2010) Modern Control Engineering. 5th edn. Upper Saddle River, NJ: Prentice Hall.
• Kalman, R.E. (1960) ‘A new approach to linear filtering and prediction problems’, Journal of Basic Engineering, 82(1), pp. 35–45.
• 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.
• Hirsch, M.W., Smale, S. and Devaney, R.L. (2013) Differential Equations, Dynamical Systems, and an Introduction to Chaos. 3rd edn. Amsterdam: Academic Press.
• Simon, H.A. (1996) The Sciences of the Artificial. 3rd edn. Cambridge, MA: MIT 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

Back to top ↑

References

• Åström, K.J. and Murray, R.M. (2021) Feedback Systems: An Introduction for Scientists and Engineers. 2nd edn. Princeton: Princeton University Press. Available at: https://fbsbook.org/
• COMAP (n.d.) Mathematical Modeling Handbook. Bedford, MA: Consortium for Mathematics and Its Applications. Available at: https://www.comap.com/membership/member-resources/item/mathematical-modeling-handbook
• 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
• Hirsch, M.W., Smale, S. and Devaney, R.L. (2013) Differential Equations, Dynamical Systems, and an Introduction to Chaos. 3rd edn. Amsterdam: Academic Press.
• Kalman, R.E. (1960) ‘A new approach to linear filtering and prediction problems’, Journal of Basic Engineering, 82(1), pp. 35–45.
• 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
• Ogata, K. (2010) Modern Control Engineering. 5th edn. Upper Saddle River, NJ: Prentice Hall.
• Simon, H.A. (1996) The Sciences of the Artificial. 3rd edn. Cambridge, MA: MIT 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 ↑