Graph Theory Foundations for Systems Modeling: How Networks Reveal Structure, Connectivity, and Flow

Last Updated July 2, 2026

Graph theory foundations for systems modeling explain how connected structure shapes system behavior. A graph represents entities as nodes and relationships as edges. This simple abstraction supports serious analysis of infrastructure, transportation, ecology, communication, supply chains, knowledge systems, power grids, social networks, financial exposure, public health contact structure, and digital platforms.

This article continues Part V of the Linear Algebra for Systems Modeling series by connecting graph theory, nodes, edges, adjacency, incidence, degree, walks, paths, trails, cycles, components, connectivity, trees, directed graphs, weighted graphs, bipartite graphs, graph Laplacians, shortest paths, network flow, centrality, sparsity, algorithms, graph data modeling, and responsible interpretation.

The central modeling question is not only “Can this system be drawn as a network?” It is “What do the nodes and edges mean, what structure is preserved by the graph, what structure is lost, and which graph-theoretic claims are justified by the system being modeled?”

Graph theory provides a vocabulary for relationships. Nodes identify system elements. Edges identify connections. Paths describe possible routes. Cycles describe loops. Components describe separated regions. Degrees describe local connectivity. Trees describe minimal connection structure. Directed graphs describe orientation. Weighted graphs describe capacity, distance, cost, strength, probability, exposure, or dependence. Matrices turn these structures into computation.

In systems modeling, graph theory is not only a mathematical subject. It is a representation discipline. A graph can clarify how a system is connected, where bottlenecks arise, how shocks propagate, which elements are structurally central, how redundancy appears, how flow moves, and how vulnerability depends on topology. But graph models can also distort systems when nodes, edges, weights, direction, time, uncertainty, or institutional meaning are poorly defined.

Why Graph Theory Matters for Systems Modeling

Graph theory matters because many systems are defined less by isolated quantities than by relationships among parts. A road network is not only a list of roads. A power grid is not only a list of substations. A supply chain is not only a list of firms. A citation system is not only a list of publications. A public-health contact network is not only a list of individuals. The relationships are part of the system.

Graph theory gives modelers a rigorous language for connected structure. It supports questions about reachability, redundancy, bottlenecks, influence, exposure, robustness, diffusion, routing, clustering, hierarchy, vulnerability, and flow. Linear algebra then turns those graph structures into matrices, operators, spectra, rankings, and computational workflows.

Graph theory helps systems modeling move from vague relational language to explicit structural claims.

Back to top ↑

Graphs, Nodes, and Edges

A graph is commonly written as:

The nodes \(V\) represent entities. The edges \(E\) represent relationships. In systems modeling, the same real-world system can produce different graphs depending on the definition of nodes and edges.

Graph modeling begins before computation. It begins with representational discipline.

Back to top ↑

Simple Graphs, Multigraphs, and Hypergraphs

Different graph types represent different relationship structures. A simple graph allows at most one edge between two nodes and usually excludes self-loops. A multigraph allows multiple edges between the same nodes. A hypergraph allows one edge to connect more than two nodes.

Forcing a complex relationship into a simple graph may discard important structure. The graph type should match the system question.

Back to top ↑

Undirected, Directed, and Weighted Graphs

Graphs may be undirected, directed, weighted, or some combination of these. An undirected edge represents mutual or symmetric connection. A directed edge represents orientation. A weighted edge assigns a value to the relationship.

Direction and weight are not decoration. They determine which mathematical operations are meaningful.

Back to top ↑

Walks, Paths, Trails, and Cycles

Graph theory distinguishes several kinds of movement through a network. These distinctions matter when modeling routing, spread, exposure, influence, redundancy, and repeated contact.

Matrix powers count walks, not necessarily simple paths. This distinction matters when interpreting adjacency powers, reachability, and propagation.

Walks are useful for propagation models, but path constraints may be necessary for routing, vulnerability, and resource-planning problems.

Back to top ↑

Connectivity and Components

Connectivity describes whether nodes can reach one another. A connected component is a maximal group of nodes where each node can reach every other node in that group through some path.

Connectivity is central to resilience and vulnerability. A system can look dense locally while still fragmented globally. It can also be connected through a small number of fragile bridges.

Back to top ↑

Degree and Local Structure

Degree measures local connectivity. In an undirected graph, the degree of a node is the number of incident edges. In directed graphs, in-degree and out-degree distinguish incoming and outgoing structure.

Degree is local. A high-degree node is not automatically important in every sense. Importance depends on the system question.

Back to top ↑

Trees, Forests, and Minimal Connection

A tree is a connected graph with no cycles. Trees are important because they represent minimal connection: enough edges to connect all nodes, but no loops.

A forest is a graph whose connected components are trees. Trees and forests appear in spanning-tree problems, hierarchical structures, branching processes, minimum-cost connection, network design, and redundancy analysis.

Tree structure is efficient but often fragile. Redundancy usually requires cycles.

Back to top ↑

Bipartite and Layered Graphs

A bipartite graph has two types of nodes, with edges only between the two types. This is useful for representing users and items, authors and papers, firms and products, species and habitats, projects and workers, or institutions and programs.

Layered and multilayer graphs extend this idea by representing multiple relationship types, time layers, infrastructure layers, or institutional layers.

Systems often require layered graph representation because physical, informational, financial, institutional, and behavioral connections may not align.

Back to top ↑

Graph Matrices

Graph theory connects naturally to linear algebra through matrix representation. The most important graph matrices include adjacency matrices, incidence matrices, degree matrices, and Laplacian matrices.

These matrices allow graph structure to be studied with linear algebra, numerical computation, and optimization.

Matrix representation makes graph analysis reproducible, but it also requires precise node ordering, edge conventions, weight definitions, and sparse computation choices.

Back to top ↑

Graph Laplacians and Structural Operators

The graph Laplacian is one of the most important operators in graph-based modeling. It combines local degree with adjacency structure and supports diffusion, smoothing, spectral clustering, cuts, consensus, electrical analogies, vibration models, and network robustness analysis.

Using an oriented incidence matrix \(B\), the unweighted Laplacian can also be written as:

Laplacian analysis is powerful, but the meaning of the operator depends on edge weights, normalization, direction handling, and graph construction.

Back to top ↑

Shortest Paths, Distance, and Reachability

Shortest-path analysis asks how far one node is from another under a chosen notion of distance. The distance may represent hops, travel time, physical length, monetary cost, energy loss, latency, risk, or another edge weight.

Shortest paths depend on weight semantics. A high weight may mean a strong connection in one model and a costly connection in another.

Back to top ↑

Centrality, Influence, and Structural Importance

Centrality measures attempt to quantify structural importance. Different centrality measures answer different questions. A node may have many direct connections, sit between otherwise separated regions, be close to many nodes, or be connected to other important nodes.

Centrality is not the same as importance in every domain. The measure must match the modeling question.

Back to top ↑

Flows, Cuts, and Bottlenecks

Flow problems study how quantities move through networks. A cut separates a graph into two node sets and identifies edges crossing that separation. Cuts often reveal bottlenecks, vulnerabilities, or capacity limits.

Flow modeling connects graph theory to optimization, infrastructure planning, logistics, reliability, and systems resilience.

Back to top ↑

Graph Algorithms and Computation

Graph theory becomes operational through algorithms. Different algorithms answer different structural questions: traversal, connectivity, shortest paths, spanning trees, components, centrality, matching, flow, clustering, and ranking.

Algorithm choice should follow the representation, graph size, sparsity, direction, weight semantics, and domain question.

Back to top ↑

Graph Data and Modeling Judgment

Graph models often look precise because they use mathematical notation and visual structure. But graph conclusions depend on data and definitions. Missing nodes, missing edges, false edges, stale weights, boundary choices, projection choices, aggregation choices, and normalization choices can reshape analysis.

Graph modeling should include provenance, uncertainty, sensitivity analysis, and interpretation warnings. A graph is a representation, not the system itself.

Back to top ↑

Graph Theory in Systems Modeling

Graph theory supports systems modeling wherever connected structure matters. It can show how systems are organized, where dependence concentrates, how pathways form, how loops create redundancy or feedback, how disruptions propagate, and how local connections produce global behavior.

Graph theory is most useful when its abstraction is kept accountable to domain structure.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer. Graph theory foundations connect combinatorics, matrix algebra, sparse computation, spectral graph theory, optimization, network flow, random walks, Markov chains, graph algorithms, graph data modeling, and systems governance.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for graph theory foundations should document node lists, edge lists, graph type, direction conventions, weight semantics, adjacency matrices, incidence matrices, degree summaries, components, shortest paths, cycles, sparsity, graph Laplacians, centrality measures, data provenance, missing-edge assumptions, and interpretation warnings.

The companion repository treats graph theory as an auditable systems-modeling layer. Python, R, Julia, SQL, Haskell, C, C++, Fortran, Rust, Go, notebooks, schemas, generated outputs, Canvas artifacts, advanced reports, and calculators each support a different layer of reproducible graph analysis.

For this article, the computational examples focus on graph construction, degree diagnostics, component detection, shortest-path exploration, cycle detection, adjacency and incidence construction, Laplacian diagnostics, and governance records for graph modeling choices.

Back to top ↑

Python Workflow: Graph Structure Audit

The Python workflow below builds a small weighted undirected infrastructure-style graph, computes degree diagnostics, connected components, shortest path distances, cycle indicators, adjacency structure, and an interpretation warning.

from __future__ import annotations

from collections import deque
from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import heapq
import json
import math


@dataclass(frozen=True)
class GraphStructureAudit:
    graph_name: str
    node_count: int
    edge_count: int
    directed: bool
    weighted: bool
    component_count: int
    max_degree: int
    min_degree: int
    average_degree: float
    has_cycle: bool
    shortest_path_water_to_health: float
    graph_density: float
    representation_warning: str


def build_graph() -> tuple[list[str], list[tuple[str, str, float]]]:
    nodes = ["water", "power", "transport", "communications", "health"]
    edges = [
        ("water", "power", 1.0),
        ("power", "transport", 1.5),
        ("power", "communications", 0.8),
        ("transport", "communications", 1.2),
        ("communications", "health", 1.0),
        ("water", "health", 2.5),
    ]
    return nodes, edges


def adjacency_list(nodes: list[str], edges: list[tuple[str, str, float]]) -> dict[str, list[tuple[str, float]]]:
    graph = {node: [] for node in nodes}
    for source, target, weight in edges:
        graph[source].append((target, weight))
        graph[target].append((source, weight))
    return graph


def connected_components(nodes: list[str], graph: dict[str, list[tuple[str, float]]]) -> list[list[str]]:
    visited: set[str] = set()
    components: list[list[str]] = []

    for node in nodes:
        if node in visited:
            continue
        queue = deque([node])
        visited.add(node)
        component = []
        while queue:
            current = queue.popleft()
            component.append(current)
            for neighbor, _weight in graph[current]:
                if neighbor not in visited:
                    visited.add(neighbor)
                    queue.append(neighbor)
        components.append(sorted(component))

    return components


def dijkstra(graph: dict[str, list[tuple[str, float]]], source: str) -> dict[str, float]:
    distances = {node: math.inf for node in graph}
    distances[source] = 0.0
    heap = [(0.0, source)]

    while heap:
        current_distance, node = heapq.heappop(heap)
        if current_distance > distances[node]:
            continue

        for neighbor, weight in graph[node]:
            candidate = current_distance + weight
            if candidate < distances[neighbor]:
                distances[neighbor] = candidate
                heapq.heappush(heap, (candidate, neighbor))

    return distances


def has_cycle_undirected(nodes: list[str], graph: dict[str, list[tuple[str, float]]]) -> bool:
    visited: set[str] = set()

    def dfs(node: str, parent: str | None) -> bool:
        visited.add(node)
        for neighbor, _weight in graph[node]:
            if neighbor not in visited:
                if dfs(neighbor, node):
                    return True
            elif neighbor != parent:
                return True
        return False

    for node in nodes:
        if node not in visited and dfs(node, None):
            return True
    return False


def write_edge_list(path: Path, edges: list[tuple[str, str, float]]) -> None:
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=["source", "target", "weight"])
        writer.writeheader()
        for source, target, weight in edges:
            writer.writerow({"source": source, "target": target, "weight": weight})


def write_degree_table(path: Path, graph: dict[str, list[tuple[str, float]]]) -> None:
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=["node", "degree", "weighted_degree"])
        writer.writeheader()
        for node, neighbors in sorted(graph.items()):
            writer.writerow({
                "node": node,
                "degree": len(neighbors),
                "weighted_degree": round(sum(weight for _neighbor, weight in neighbors), 8),
            })


def build_audit() -> tuple[GraphStructureAudit, list[str], list[tuple[str, str, float]], dict[str, list[tuple[str, float]]]]:
    nodes, edges = build_graph()
    graph = adjacency_list(nodes, edges)
    components = connected_components(nodes, graph)
    degrees = [len(graph[node]) for node in nodes]
    distances = dijkstra(graph, "water")
    n = len(nodes)
    possible_edges = n * (n - 1) / 2
    density = len(edges) / possible_edges

    audit = GraphStructureAudit(
        graph_name="synthetic_infrastructure_graph_foundations",
        node_count=n,
        edge_count=len(edges),
        directed=False,
        weighted=True,
        component_count=len(components),
        max_degree=max(degrees),
        min_degree=min(degrees),
        average_degree=round(sum(degrees) / n, 12),
        has_cycle=has_cycle_undirected(nodes, graph),
        shortest_path_water_to_health=round(distances["health"], 12),
        graph_density=round(density, 12),
        representation_warning=(
            "Graph conclusions depend on node definitions, edge definitions, graph boundary, "
            "direction conventions, weight semantics, missing edges, time period, and data provenance."
        ),
    )

    return audit, nodes, edges, graph


def write_outputs(output_dir: Path) -> None:
    (output_dir / "tables").mkdir(parents=True, exist_ok=True)
    (output_dir / "json").mkdir(parents=True, exist_ok=True)

    audit, nodes, edges, graph = build_audit()
    row = asdict(audit)

    with (output_dir / "tables" / "graph_structure_audit.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=list(row.keys()))
        writer.writeheader()
        writer.writerow(row)

    write_edge_list(output_dir / "tables" / "graph_edge_list.csv", edges)
    write_degree_table(output_dir / "tables" / "graph_degree_table.csv", graph)

    (output_dir / "json" / "graph_structure_audit.json").write_text(
        json.dumps(row, indent=2, sort_keys=True),
        encoding="utf-8",
    )


if __name__ == "__main__":
    write_outputs(Path("outputs"))
    print("Graph structure audit complete.")

This workflow keeps graph construction, degree diagnostics, component structure, shortest-path behavior, cycle status, and interpretation warnings together.

Back to top ↑

R Workflow: Graph Diagnostics

R can support graph-theory diagnostics by computing degrees, weighted degrees, density, connectedness, and shortest-path summaries from an edge list.

nodes <- c("water", "power", "transport", "communications", "health")

edges <- data.frame(
  source = c("water", "power", "power", "transport", "communications", "water"),
  target = c("power", "transport", "communications", "communications", "health", "health"),
  weight = c(1.0, 1.5, 0.8, 1.2, 1.0, 2.5)
)

degree_table <- data.frame(
  node = nodes,
  degree = integer(length(nodes)),
  weighted_degree = numeric(length(nodes))
)

for (i in seq_len(nrow(edges))) {
  s <- edges$source[i]
  t <- edges$target[i]
  w <- edges$weight[i]

  degree_table$degree[degree_table$node == s] <- degree_table$degree[degree_table$node == s] + 1
  degree_table$degree[degree_table$node == t] <- degree_table$degree[degree_table$node == t] + 1

  degree_table$weighted_degree[degree_table$node == s] <- degree_table$weighted_degree[degree_table$node == s] + w
  degree_table$weighted_degree[degree_table$node == t] <- degree_table$weighted_degree[degree_table$node == t] + w
}

node_count <- length(nodes)
edge_count <- nrow(edges)
graph_density <- edge_count / (node_count * (node_count - 1) / 2)

audit_record <- data.frame(
  graph_name = "synthetic_infrastructure_graph_foundations",
  node_count = node_count,
  edge_count = edge_count,
  directed = FALSE,
  weighted = TRUE,
  max_degree = max(degree_table$degree),
  min_degree = min(degree_table$degree),
  average_degree = mean(degree_table$degree),
  graph_density = graph_density,
  representation_warning = paste(
    "Graph conclusions depend on node definitions, edge definitions, graph boundary,",
    "direction conventions, weight semantics, missing edges, time period, and data provenance."
  )
)

dir.create("outputs/tables", recursive = TRUE, showWarnings = FALSE)

write.csv(audit_record, "outputs/tables/r_graph_structure_audit.csv", row.names = FALSE)
write.csv(edges, "outputs/tables/r_graph_edge_list.csv", row.names = FALSE)
write.csv(degree_table, "outputs/tables/r_graph_degree_table.csv", row.names = FALSE)

print(audit_record)

This R workflow preserves the graph edge list and degree summaries as auditable modeling artifacts.

Back to top ↑

Haskell Workflow: Typed Graph Records

Haskell can represent graph diagnostics as typed records, keeping graph type, density, degree structure, and representation warning attached to the summary.

module Main where

data GraphStructureAudit = GraphStructureAudit
  { graphName :: String
  , nodeCount :: Int
  , edgeCount :: Int
  , directed :: Bool
  , weighted :: Bool
  , componentCount :: Int
  , maxDegree :: Int
  , minDegree :: Int
  , averageDegree :: Double
  , hasCycle :: Bool
  , graphDensity :: Double
  , representationWarning :: String
  } deriving (Show)

buildAudit :: GraphStructureAudit
buildAudit =
  GraphStructureAudit
    "synthetic_infrastructure_graph_foundations"
    5
    6
    False
    True
    1
    3
    2
    2.4
    True
    0.6
    "Graph conclusions depend on node definitions, edge definitions, graph boundary, direction conventions, weight semantics, missing edges, time period, and data provenance."

main :: IO ()
main =
  print buildAudit

The typed record helps keep graph metrics tied to representation choices.

Back to top ↑

SQL Workflow: Graph Modeling Registry

SQL can document graph-modeling assumptions when graph theory supports infrastructure analysis, knowledge systems, platform governance, supply-chain review, ecological modeling, transportation planning, or institutional decision systems.

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

INSERT INTO graph_modeling_registry VALUES
(
  'node_definition',
  'Node definition',
  'Defines the elements of the vertex set V.',
  'Determines what entities the graph can represent.',
  'Changing node definitions can change every graph metric.'
);

INSERT INTO graph_modeling_registry VALUES
(
  'edge_definition',
  'Edge definition',
  'Defines the relationships in the edge set E.',
  'Determines what counts as connection, flow, dependence, or interaction.',
  'Different edge definitions can produce different systems conclusions.'
);

INSERT INTO graph_modeling_registry VALUES
(
  'graph_boundary',
  'Graph boundary',
  'Defines what is included in or excluded from the graph.',
  'Determines whether the modeled system is complete, partial, local, or sampled.',
  'Excluded nodes and edges can distort connectivity and vulnerability claims.'
);

INSERT INTO graph_modeling_registry VALUES
(
  'direction_convention',
  'Direction convention',
  'Defines orientation for directed edges.',
  'Determines how reachability, influence, citation, dependency, and flow are interpreted.',
  'Reversing directions can reverse substantive conclusions.'
);

INSERT INTO graph_modeling_registry VALUES
(
  'weight_semantics',
  'Weight semantics',
  'Defines numeric meaning of edge weights.',
  'Determines whether weights represent distance, capacity, cost, frequency, exposure, or similarity.',
  'Weights with different meanings require different algorithms and transformations.'
);

INSERT INTO graph_modeling_registry VALUES
(
  'temporal_scope',
  'Temporal scope',
  'Defines the time period represented by nodes and edges.',
  'Determines whether the graph is static, historical, dynamic, or streaming.',
  'Static graphs can hide time ordering and changing structure.'
);

INSERT INTO graph_modeling_registry VALUES
(
  'metric_interpretation',
  'Metric interpretation',
  'Defines how graph metrics should be read in domain context.',
  'Determines whether degree, centrality, distance, or cuts have substantive meaning.',
  'Graph metrics are structural indicators, not automatic explanations.'
);

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

This registry keeps graph-theory workflows tied to node definitions, edge definitions, boundaries, direction, weights, time, and responsible interpretation.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It supports graph-structure audits, node and edge lists, degree diagnostics, component checks, shortest-path summaries, cycle detection, graph matrix construction, SQL governance tables, generated outputs, advanced mathematical audit reports, and reusable calculator scripts.

Back to top ↑

Interpretive Limits and Responsible Use

Graph theory is powerful because it makes relational structure explicit. It can reveal paths, components, cycles, centrality, distance, connectivity, cuts, bottlenecks, redundancy, flow constraints, and vulnerability. Its limits arise because the graph is not the system itself. A graph is a representation created by choices about nodes, edges, boundaries, direction, weights, time, evidence, aggregation, and missing data.

Graph metrics can be misleading when their meaning is detached from the domain. Degree is not automatically influence. Betweenness is not automatically power. A shortest path is not automatically a feasible route. A component is not automatically an institutionally meaningful subsystem. A high-weight edge can mean capacity, cost, exposure, probability, or similarity depending on the model. A central node may be central because of measurement bias rather than system importance.

Responsible use requires documenting graph construction, node definitions, edge definitions, graph type, direction convention, weight semantics, temporal scope, data provenance, uncertainty, missingness, algorithm choice, sensitivity analysis, and interpretive limits. Graph theory should make connected structure clearer, not hide modeling choices behind compelling network diagrams or centrality scores.

Back to top ↑

Related Articles

• What Is Linear Algebra for Systems Modeling?
• Network Adjacency Matrices
• Incidence Structure and Graph Representation
• PageRank and Network Influence Models
• Network Flow Modeling
• Infrastructure Network Models
• Flow, Connectivity, and System Vulnerability
• Matrices and the Organization of Multivariable Systems
• Matrix Multiplication and Interaction Effects
• Linear Transformations and Model Behavior
• Eigenvalues, Eigenvectors, and System Modes
• Stability Analysis with Eigenvalues
• Markov Chains and Transition Matrices
• Linear Dynamical Systems
• Control Systems Modeling
• Linear Algebra for Systems Modeling
• Mathematical Modeling
• Systems Modeling
• Algorithms & Computational Reasoning
• Scientific Computing for Systems Modeling

Back to top ↑

Further Reading

• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/.
• Bollobás, B. (1998) Modern Graph Theory. New York: Springer. Available at: https://link.springer.com/book/10.1007/978-1-4612-0619-4.
• Bondy, J.A. and Murty, U.S.R. (2008) Graph Theory. London: Springer. Available at: https://link.springer.com/book/10.1007/978-1-84628-970-5.
• Boyd, S. and Vandenberghe, L. (2018) Introduction to Applied Linear Algebra: Vectors, Matrices, and Least Squares. Cambridge: Cambridge University Press. Available at: https://vmls-book.stanford.edu/.
• Chung, F.R.K. (1997) Spectral Graph Theory. Providence, RI: American Mathematical Society. Available at: https://www.ams.org/books/cbms/092/.
• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262046305/introduction-to-algorithms/.
• Diestel, R. (2024) Graph Theory. 6th edn. Berlin: Springer. Available at: https://diestel-graph-theory.com/.
• Easley, D. and Kleinberg, J. (2010) Networks, Crowds, and Markets: Reasoning About a Highly Connected World. Cambridge: Cambridge University Press. Available at: https://www.cs.cornell.edu/home/kleinber/networks-book/.
• Godsil, C. and Royle, G. (2001) Algebraic Graph Theory. New York: Springer. Available at: https://link.springer.com/book/10.1007/978-1-4613-0163-9.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• NetworkX Developers (n.d.) NetworkX Documentation. Available at: https://networkx.org/documentation/stable/.
• SciPy Developers (n.d.) Sparse Arrays: scipy.sparse. SciPy Documentation. Available at: https://docs.scipy.org/doc/scipy/reference/sparse.html.
• West, D.B. (2001) Introduction to Graph Theory. 2nd edn. Upper Saddle River, NJ: Prentice Hall. Available at: https://faculty.math.illinois.edu/~west/igt/.

Back to top ↑

References

• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/.
• Bollobás, B. (1998) Modern Graph Theory. New York: Springer. Available at: https://link.springer.com/book/10.1007/978-1-4612-0619-4.
• Bondy, J.A. and Murty, U.S.R. (2008) Graph Theory. London: Springer. Available at: https://link.springer.com/book/10.1007/978-1-84628-970-5.
• Boyd, S. and Vandenberghe, L. (2018) Introduction to Applied Linear Algebra: Vectors, Matrices, and Least Squares. Cambridge: Cambridge University Press. Available at: https://vmls-book.stanford.edu/.
• Chung, F.R.K. (1997) Spectral Graph Theory. Providence, RI: American Mathematical Society. Available at: https://www.ams.org/books/cbms/092/.
• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262046305/introduction-to-algorithms/.
• Diestel, R. (2024) Graph Theory. 6th edn. Berlin: Springer. Available at: https://diestel-graph-theory.com/.
• Easley, D. and Kleinberg, J. (2010) Networks, Crowds, and Markets: Reasoning About a Highly Connected World. Cambridge: Cambridge University Press. Available at: https://www.cs.cornell.edu/home/kleinber/networks-book/.
• Godsil, C. and Royle, G. (2001) Algebraic Graph Theory. New York: Springer. Available at: https://link.springer.com/book/10.1007/978-1-4613-0163-9.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• NetworkX Developers (n.d.) NetworkX Documentation. Available at: https://networkx.org/documentation/stable/.
• SciPy Developers (n.d.) Sparse Arrays: scipy.sparse. SciPy Documentation. Available at: https://docs.scipy.org/doc/scipy/reference/sparse.html.
• West, D.B. (2001) Introduction to Graph Theory. 2nd edn. Upper Saddle River, NJ: Prentice Hall. Available at: https://faculty.math.illinois.edu/~west/igt/.

Back to top ↑