Algebraic Models and Static Relationships: How Mathematical Models Connect Variables

Last Updated June 12, 2026

Algebraic models and static relationships describe systems through equations, formulas, constraints, and proportional structures that do not explicitly track change over time. They are often the first formal models people encounter because they connect variables directly: price to quantity, area to length, risk to exposure, cost to volume, demand to income, or output to inputs.

An algebraic model does not require a time index, differential equation, recurrence rule, or simulation loop. Instead, it represents how quantities relate under a defined set of assumptions. Some algebraic models are simple formulas. Others are systems of equations, nonlinear relationships, equilibrium conditions, optimization constraints, or static approximations to complex systems.

Static does not mean shallow. A static model can encode important structure: conservation, trade-offs, feasibility, elasticity, saturation, equilibrium, proportional scaling, or resource limits. The key question is whether the algebraic relationship is appropriate for the model’s purpose, scale, units, data, assumptions, and interpretation.

Algebraic modeling is especially useful when the purpose is to define a relationship, estimate a static effect, compare scenarios, calculate feasible ranges, solve for unknowns, or describe an equilibrium condition. It is less appropriate when the central question depends on time evolution, feedback delay, path dependence, accumulation, adaptation, or state change. The discipline is knowing when a static representation clarifies and when it conceals.

Why Algebraic Models Matter

Algebraic models matter because many modeling questions begin with direct relationships among quantities. How much does total cost depend on quantity? How does exposure combine with vulnerability to estimate risk? What output is expected from a given input level? What allocation satisfies a budget constraint? What price balances supply and demand? What production level is feasible under limited resources?

These questions do not always require a dynamic model. They may require a clear algebraic relationship, a set of constraints, a parameterized formula, or a static scenario comparison. Algebraic models are often compact, interpretable, computationally efficient, and easy to communicate.

Because algebraic models are concise, they can appear self-evident. That is risky. Their assumptions, units, domains, and parameter meanings still need review. A formula can be transparent and still wrong for the purpose at hand.

Back to top ↑

What an Algebraic Model Is

An algebraic model represents relationships among quantities using algebraic expressions, equations, inequalities, systems of equations, or constraint sets. It usually does not describe explicit time evolution. Instead, it connects variables within a defined situation, scenario, or equilibrium condition.

A model may involve many variables:

Algebraic models can be descriptive, explanatory, predictive, diagnostic, prescriptive, or normative. The same formula can serve different purposes depending on how it is used.

An algebraic model is useful when the structure of interest is relational rather than explicitly temporal. It asks how quantities fit together under a specified set of conditions.

Back to top ↑

What Static Relationships Represent

A static relationship describes a connection among variables without explicitly modeling how that connection unfolds through time. Static relationships can represent a snapshot, an equilibrium, a scenario, a steady-state condition, or an assumed direct relationship.

Static does not mean that the real system never changes. It means that the model is not representing change as a process. A static model of demand may show quantity demanded at a given price. A dynamic demand model would represent how demand evolves over time in response to price, income, habit, supply, expectations, and feedback.

A static relationship is appropriate when the modeling purpose is comparison, definition, estimation, feasibility, equilibrium, or approximation. It is risky when the central issue is accumulation, path dependence, learning, adaptation, or delay.

Back to top ↑

Identities, Balances, and Definitions

Some algebraic models are identities. They are true by definition, accounting structure, or conservation rule. Others are balances, where quantities must add up or satisfy a relationship. These models are foundational because they clarify what is being counted, combined, or conserved.

Identities and balances can be powerful because they reduce ambiguity. They also reveal data gaps. If one term in a balance is unknown, the model can show which measurement or assumption is carrying the uncertainty.

An identity can still be misleading if its categories are poorly defined, its units are inconsistent, or its components hide important differences. Algebraic clarity depends on conceptual clarity.

Back to top ↑

Linear Algebraic Models

Linear algebraic models represent relationships in which change in one variable produces a constant marginal change in another, holding other conditions fixed. Linear models are widely used because they are simple, interpretable, and often useful as approximations.

With multiple variables, the linear model becomes:

Linear relationships are not automatically wrong or simplistic. They are useful when constant marginal effects are plausible, when the model is local, when interpretation matters, or when a simple baseline is needed. But linearity should be treated as an assumption, not a default truth.

Back to top ↑

Nonlinear Algebraic Relationships

Nonlinear algebraic models represent relationships where marginal effects change with the level of the variables. Many real systems show saturation, thresholds, diminishing returns, acceleration, curvature, or interaction effects that cannot be captured by a simple linear relationship.

Nonlinear models can be more realistic, but they also require more care. Parameters may be harder to estimate. Extrapolation may be dangerous. Outputs may be sensitive to domain boundaries. A nonlinear equation should be chosen because its shape fits the mechanism or evidence, not because it looks sophisticated.

Back to top ↑

Proportionality, Ratios, and Scaling Laws

Many algebraic models are built from proportionality, ratios, and scaling relationships. These forms make comparison possible. They can express density, efficiency, exposure, productivity, elasticity, per-capita burden, normalized risk, or size-dependent behavior.

Ratios are powerful but often misunderstood. A per-capita value is not the same as a total value. A percentage is not the same as a count. A normalized score depends on its denominator or reference scale. A ratio with a small denominator may become unstable.

Proportionality and scaling relationships are especially useful for comparison across systems. They also require clear units, denominators, reference values, and validity ranges.

Back to top ↑

Equilibrium and Static Optimization

Algebraic models often describe equilibrium conditions or optimization problems. An equilibrium is a condition where relationships balance under the model’s assumptions. A static optimization problem selects values that maximize or minimize an objective subject to constraints, without explicitly modeling time evolution.

Equilibrium and optimization models can clarify trade-offs, feasibility, and best-case outcomes. But they can also conceal process, power, uncertainty, and adjustment costs if interpreted too broadly.

A static optimum is not the same as a responsible decision. It depends on the objective, constraints, parameter values, available alternatives, and interpretation of the modeled system.

Back to top ↑

Constraints and Feasible Regions

Algebraic models often define constraints. Constraints describe what is allowed, possible, affordable, safe, legal, or meaningful. They can be equations, inequalities, bounds, domain restrictions, or logical rules.

Constraints should be documented with their source. A physical constraint differs from a policy constraint. A safety constraint differs from a computational convenience. A legal constraint differs from a modeling assumption. Feasible regions are not purely mathematical; they encode judgment.

Back to top ↑

Algebraic Models Versus Dynamic Models

The difference between algebraic and dynamic models is not that one is simple and the other is complex. The difference is whether the model explicitly represents change over time through state updates, recurrence, differential equations, or simulation.

Algebraic models can be embedded inside dynamic models. A dynamic model may use algebraic equations for output, constraints, equilibrium conditions, or instantaneous relationships. In this sense, algebraic modeling is not replaced by dynamic modeling; it often provides building blocks for it.

The modeling task is to choose the least complicated representation that is adequate for the question, not to choose the most advanced mathematical form available.

Back to top ↑

Model Purpose and Algebraic Structure

The structure of an algebraic model should follow its purpose. A model designed for explanation may prioritize transparent relationships. A model designed for prediction may prioritize empirical fit. A model designed for feasibility may prioritize constraints. A model designed for decision support may need scenario comparison and uncertainty communication.

A formula should not be separated from its purpose. A relationship that is useful for communication may be inadequate for control. A formula that predicts well may not explain causality. A constraint model may identify feasibility without deciding legitimacy.

Back to top ↑

Mathematical Lens: Algebraic Models as Mappings and Constraint Sets

An algebraic model can be viewed as a mapping from inputs and parameters to outputs:

When constraints matter, the model may be defined only on a feasible domain:

A static optimization model combines mapping, objective, and feasibility:

A sensitivity measure can examine how outputs change with parameters:

This lens shows that algebraic models are not merely formulas. They have domains, mappings, parameters, constraints, objectives, and interpretations. Each part should be explicit.

Back to top ↑

Example: A Static Resource Allocation Model

Consider a static resource allocation problem. A planner has a fixed budget \(B\), a unit cost \(c_i\) for each option \(i\), and an expected benefit \(b_i\). The goal is to choose allocation amounts \(x_i\) that maximize total benefit without exceeding the budget or capacity limits.

This model is algebraic and static. It does not show how allocations are implemented over time, how capacity changes, how demand adapts, or how feedback occurs. But it can clarify trade-offs, feasibility, and the structure of a decision problem.

Back to top ↑

Validation, Sensitivity, and Algebraic Adequacy

Validation of algebraic models asks whether the relationship is appropriate for its purpose, whether its units and domains are correct, whether its parameters are credible, and whether its outputs are plausible. A formula can be mathematically correct but inappropriate for the system being modeled.

Sensitivity analysis is especially important because algebraic models often look precise. Small changes in a parameter, exponent, denominator, or constraint can change results. Static does not mean certain.

Back to top ↑

Ethical Stakes of Algebraic Modeling

Algebraic models can carry ethical stakes because they often make decisions look clean. A cost formula can omit unpaid labor. A risk score can hide vulnerability. An optimization objective can privilege efficiency over fairness. A feasibility constraint can encode political assumptions as if they were technical facts.

Responsible algebraic modeling does not require avoiding formulas. It requires making clear what the formula represents, what it leaves out, and how its outputs should and should not be used.

Back to top ↑

Python Workflow: Algebraic Relationship Register and Scenario Audit

The Python workflow below treats algebraic relationships as reviewable model objects. It defines a relationship register, evaluates static allocation scenarios, checks constraints, and exports scenario summaries and an audit card.

# algebraic_models_static_relationships_workflow.py
# Dependency-light workflow for algebraic model and static relationship review.

from __future__ import annotations

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


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


@dataclass(frozen=True)
class AlgebraicRelationship:
    key: str
    relationship_type: str
    expression: str
    interpretation: str
    domain_or_constraint: str
    review_question: str
    status: str


@dataclass(frozen=True)
class AllocationScenario:
    name: str
    budget: float
    cost_a: float
    cost_b: float
    benefit_a: float
    benefit_b: float
    allocation_a: float
    allocation_b: float
    capacity_a: float
    capacity_b: float


def relationship_register() -> list[AlgebraicRelationship]:
    return [
        AlgebraicRelationship(
            key="total_cost",
            relationship_type="identity",
            expression="C = c_a*x_a + c_b*x_b",
            interpretation="Total cost is the sum of option-specific costs.",
            domain_or_constraint="x_a >= 0, x_b >= 0",
            review_question="Are costs complete and expressed in comparable units?",
            status="active",
        ),
        AlgebraicRelationship(
            key="budget_constraint",
            relationship_type="inequality",
            expression="c_a*x_a + c_b*x_b <= B",
            interpretation="Total modeled cost must not exceed budget.",
            domain_or_constraint="B > 0",
            review_question="Is the budget a hard constraint or a policy assumption?",
            status="review",
        ),
        AlgebraicRelationship(
            key="benefit_objective",
            relationship_type="objective",
            expression="V = b_a*x_a + b_b*x_b",
            interpretation="Total modeled benefit is additive across allocations.",
            domain_or_constraint="benefit units must be comparable",
            review_question="Does additive benefit omit equity, risk, or implementation limits?",
            status="review",
        ),
        AlgebraicRelationship(
            key="capacity_bounds",
            relationship_type="bounds",
            expression="0 <= x_i <= K_i",
            interpretation="Each allocation is bounded by option-specific capacity.",
            domain_or_constraint="K_i >= 0",
            review_question="Are capacity bounds measured, assumed, or policy-defined?",
            status="review",
        ),
    ]


def validate_scenario(scenario: AllocationScenario) -> None:
    numeric_fields = asdict(scenario)
    for key, value in numeric_fields.items():
        if key == "name":
            continue
        if float(value) < 0:
            raise ValueError(f"{key} must be nonnegative.")
    if scenario.budget <= 0:
        raise ValueError("budget must be positive.")
    if scenario.cost_a <= 0 or scenario.cost_b <= 0:
        raise ValueError("costs must be positive.")


def evaluate_scenario(scenario: AllocationScenario) -> dict[str, object]:
    validate_scenario(scenario)

    total_cost = scenario.cost_a * scenario.allocation_a + scenario.cost_b * scenario.allocation_b
    total_benefit = scenario.benefit_a * scenario.allocation_a + scenario.benefit_b * scenario.allocation_b

    budget_slack = scenario.budget - total_cost
    capacity_slack_a = scenario.capacity_a - scenario.allocation_a
    capacity_slack_b = scenario.capacity_b - scenario.allocation_b

    feasible = (
        budget_slack >= 0
        and capacity_slack_a >= 0
        and capacity_slack_b >= 0
        and scenario.allocation_a >= 0
        and scenario.allocation_b >= 0
    )

    benefit_per_cost = total_benefit / total_cost if total_cost > 0 else 0.0

    return {
        "scenario": scenario.name,
        "budget": round(scenario.budget, 8),
        "total_cost": round(total_cost, 8),
        "total_benefit": round(total_benefit, 8),
        "benefit_per_cost": round(benefit_per_cost, 8),
        "budget_slack": round(budget_slack, 8),
        "capacity_slack_a": round(capacity_slack_a, 8),
        "capacity_slack_b": round(capacity_slack_b, 8),
        "feasible": feasible,
        "constraint_status": "feasible" if feasible else "constraint violation",
    }


def relationship_risk_score(record: AlgebraicRelationship) -> float:
    score = {"active": 1.0, "review": 5.0, "revise": 8.0, "archive": 2.0}.get(
        record.status.lower(),
        4.0,
    )
    text = f"{record.relationship_type} {record.expression} {record.review_question}".lower()
    for term in ["constraint", "objective", "budget", "capacity", "equity", "domain", "units"]:
        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 = [
        AllocationScenario("balanced_feasible", 100.0, 4.0, 5.0, 8.0, 11.0, 10.0, 8.0, 20.0, 15.0),
        AllocationScenario("budget_stress", 80.0, 4.0, 5.0, 8.0, 11.0, 12.0, 8.0, 20.0, 15.0),
        AllocationScenario("capacity_stress", 120.0, 4.0, 5.0, 8.0, 11.0, 25.0, 5.0, 20.0, 15.0),
        AllocationScenario("high_benefit_b", 100.0, 4.0, 5.0, 8.0, 14.0, 8.0, 10.0, 20.0, 15.0),
    ]

    relationship_rows = [
        {**asdict(record), "relationship_risk_score": relationship_risk_score(record)}
        for record in relationship_register()
    ]

    scenario_rows = [evaluate_scenario(scenario) for scenario in scenarios]

    write_csv(TABLES / "algebraic_relationship_register.csv", relationship_rows)
    write_csv(TABLES / "static_allocation_scenarios.csv", scenario_rows)

    write_json(JSON_DIR / "algebraic_model_audit_card.json", {
        "article": "Algebraic Models and Static Relationships",
        "relationships": relationship_rows,
        "scenario_summaries": scenario_rows,
        "audit_checks": [
            "equations have stated interpretation",
            "units and domains are visible",
            "constraints are checked separately from objectives",
            "ratios report numerator and denominator meaning",
            "static conclusions are not overextended to dynamic behavior",
        ],
    })

    print("Algebraic models and static relationships workflow complete.")
    print(f"Wrote outputs to {OUTPUTS}")


if __name__ == "__main__":
    main()

This workflow keeps the algebraic relationship, objective, budget constraint, and capacity bounds visible as separate design objects. It also distinguishes a high-scoring scenario from a feasible scenario, which is essential in static decision support.

Back to top ↑

R Workflow: Static Relationship Diagnostics

The R workflow below reviews generated algebraic scenario outputs, classifies feasibility, and creates a simple diagnostic plot comparing total benefit and budget slack across scenarios.

# algebraic_models_static_relationships_review.R
# Base R workflow for static relationship 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)

scenario_path <- file.path(tables_dir, "static_allocation_scenarios.csv")
relationship_path <- file.path(tables_dir, "algebraic_relationship_register.csv")

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

scenario_data <- read.csv(scenario_path, stringsAsFactors = FALSE)

scenario_data$review_priority <- ifelse(
  scenario_data$feasible == "False" | scenario_data$feasible == FALSE,
  "high",
  ifelse(scenario_data$budget_slack <= 10, "medium", "low")
)

write.csv(
  scenario_data,
  file.path(tables_dir, "r_static_relationship_review_summary.csv"),
  row.names = FALSE
)

if (file.exists(relationship_path)) {
  relationships <- read.csv(relationship_path, stringsAsFactors = FALSE)

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

  write.csv(
    relationships,
    file.path(tables_dir, "r_algebraic_relationship_review_queue.csv"),
    row.names = FALSE
  )
}

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

barplot(
  height = rbind(scenario_data$total_benefit, scenario_data$budget_slack),
  beside = TRUE,
  names.arg = scenario_data$scenario,
  las = 2,
  ylab = "Value",
  main = "Static Algebraic Scenario Diagnostics"
)

legend(
  "topright",
  legend = c("Total benefit", "Budget slack"),
  fill = gray.colors(2)
)

grid()
dev.off()

print(scenario_data)

The R layer helps identify whether high-benefit scenarios are actually feasible and whether constraints are close enough to require further review.

Back to top ↑

Haskell Workflow: Typed Algebraic Relationships

Haskell is useful for this article because identities, constraints, objectives, ratios, and fitted relationships should not collapse into the same informal category. A typed layer keeps relationship roles explicit.

{-# OPTIONS_GHC -Wall #-}

module Main where

data RelationshipType
  = Identity
  | LinearRelationship
  | NonlinearRelationship
  | InequalityConstraint
  | ObjectiveFunction
  | RatioDefinition
  deriving (Eq, Show)

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

data AlgebraicRelationship = AlgebraicRelationship
  { key :: String
  , relationshipType :: RelationshipType
  , expression :: String
  , interpretation :: String
  , domainOrConstraint :: String
  , status :: ReviewStatus
  } deriving (Eq, Show)

relationships :: [AlgebraicRelationship]
relationships =
  [ AlgebraicRelationship
      "total_cost"
      Identity
      "C = c_a*x_a + c_b*x_b"
      "Total cost is the sum of option-specific costs."
      "x_a >= 0, x_b >= 0"
      Active
  , AlgebraicRelationship
      "budget_constraint"
      InequalityConstraint
      "c_a*x_a + c_b*x_b <= B" "Total modeled cost must not exceed budget." "B > 0"
      RequiresReview
  , AlgebraicRelationship
      "benefit_objective"
      ObjectiveFunction
      "V = b_a*x_a + b_b*x_b"
      "Total modeled benefit is additive across allocations."
      "benefit units must be comparable"
      RequiresValidation
  , AlgebraicRelationship
      "benefit_per_cost"
      RatioDefinition
      "r = V / C"
      "Benefit per unit cost."
      "C > 0"
      RequiresSensitivityTest
  ]

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

main :: IO ()
main = do
  putStrLn "Typed algebraic relationships:"
  mapM_ print relationships

  putStrLn "\nRelationships requiring review:"
  mapM_ print (filter needsReview relationships)

This typed layer supports model governance by making each algebraic statement’s role, domain, interpretation, and review status visible.

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 algebraic relationship registers, static scenario audits, feasibility checks, constraint diagnostics, typed Haskell relationship records, validation planning, and reproducible engineering/statistical workflows.

Back to top ↑

A Practical Method for Algebraic Model Design

Algebraic model design should begin with the relationship being represented, not with a convenient formula. The method below can be used before coding, during model review, or before publishing results.

This method helps prevent algebraic models from becoming unexamined formulas. It keeps relationship type, units, constraints, assumptions, and purpose visible.

Back to top ↑

Common Pitfalls

Algebraic models are easy to write and easy to misuse. Many failures come from treating a formula as self-explanatory when its assumptions and domains are doing hidden work.

• Formula without purpose: using an equation without specifying whether it defines, explains, predicts, constrains, or optimizes.
• Static overreach: using a static relationship to make claims about dynamic behavior.
• Unit mismatch: combining quantities that do not share compatible dimensions.
• Hidden domain limits: applying a relationship outside the range where it is valid.
• Linear default bias: assuming constant marginal effects because linear models are convenient.
• Nonlinear sophistication bias: choosing nonlinear form without evidence or interpretability.
• Ratio confusion: interpreting normalized values without explaining denominators.
• Constraint ambiguity: failing to state whether a constraint is physical, legal, ethical, budgetary, or assumed.
• Objective-function blindness: treating a value-laden objective as neutral mathematics.
• Extrapolation: extending a fitted relationship far beyond its data range.

These pitfalls can be reduced through relationship registers, unit checks, domain checks, scenario comparisons, alternative-form tests, sensitivity analysis, and clear communication of model limits.

Back to top ↑

Conclusion: Static Relationships Still Carry Model Logic

Algebraic models and static relationships are foundational tools in mathematical modeling. They define quantities, connect variables, express balances, impose constraints, estimate relationships, compare scenarios, and support decisions. They can be simple without being simplistic.

The strength of an algebraic model is clarity. A well-designed algebraic relationship can make assumptions visible, identify trade-offs, check feasibility, and provide a compact representation of a system. Its weakness is the temptation to overextend. A static model does not automatically explain dynamics, feedback, delay, adaptation, or history.

Good algebraic modeling requires attention to purpose, units, domains, parameter meanings, constraints, sensitivity, validation, and interpretation. A formula is not just notation. It is a claim about how quantities fit together.

Static relationships still carry model logic. They deserve the same discipline as more complex mathematical models.

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
• Variables, Parameters, and Constraints
• Functional Relationships and Mathematical Structure
• Equations, Inequalities, and Model Logic
• Dimensional Analysis, Units, and Scale
• State Variables and System Representation
• Differential Equations and Dynamic Models
• Optimization Models and Objective Functions
• Simulation and Computational Modeling

Back to top ↑

Further Reading

• Boyd, S. and Vandenberghe, L. (2004) Convex Optimization. Cambridge: Cambridge University Press. Available at: https://web.stanford.edu/~boyd/cvxbook/
• Chiang, A.C. and Wainwright, K. (2005) Fundamental Methods of Mathematical Economics. 4th edn. New York: McGraw-Hill.
• 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
• Giordano, F.R., Fox, W.P., Horton, S.B. and Weir, M.D. (2013) A First Course in Mathematical Modeling. 5th edn. Boston: Brooks/Cole.
• 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
• Meerschaert, M.M. (2013) Mathematical Modeling. 4th edn. Amsterdam: 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
• Saltelli, A., Tarantola, S., Campolongo, F. and Ratto, M. (2008) Global Sensitivity Analysis: The Primer. Chichester: Wiley.
• Strang, G. (2019) Linear Algebra and Learning from Data. Wellesley, MA: Wellesley-Cambridge Press. Available at: https://math.mit.edu/~gs/learningfromdata/

Back to top ↑

References

• Boyd, S. and Vandenberghe, L. (2004) Convex Optimization. Cambridge: Cambridge University Press. Available at: https://web.stanford.edu/~boyd/cvxbook/
• Chiang, A.C. and Wainwright, K. (2005) Fundamental Methods of Mathematical Economics. 4th edn. New York: McGraw-Hill.
• 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
• Giordano, F.R., Fox, W.P., Horton, S.B. and Weir, M.D. (2013) A First Course in Mathematical Modeling. 5th edn. Boston: Brooks/Cole.
• 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
• Meerschaert, M.M. (2013) Mathematical Modeling. 4th edn. Amsterdam: 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
• Saltelli, A., Tarantola, S., Campolongo, F. and Ratto, M. (2008) Global Sensitivity Analysis: The Primer. Chichester: Wiley.
• Strang, G. (2019) Linear Algebra and Learning from Data. Wellesley, MA: Wellesley-Cambridge Press. Available at: https://math.mit.edu/~gs/learningfromdata/

Back to top ↑