Representation and the Shape of Computation: How Data Structures Shape Algorithms

Last Updated June 17, 2026

Representation is one of the hidden foundations of computation. Before an algorithm can search, compare, rank, classify, retrieve, transform, optimize, or reason, something must be represented in a form the algorithm can work with. The representation determines what the system can see, what it can ignore, what it can store, what it can count, what it can compare, and what kinds of operations become easy or difficult.

This means representation is not a neutral preliminary step. It shapes computation from the beginning. A problem represented as a list invites one set of procedures. A problem represented as a graph invites another. A problem represented as a table, tree, vector, stack, queue, index, schema, image, embedding, document, or state space changes what an algorithm can do.

The shape of computation follows the shape of representation. Good representation preserves the structure needed for the task. Poor representation hides important relationships, creates unnecessary complexity, encourages misleading outputs, or makes a computational system appear more knowledgeable than it is. This article explains representation as a central act of computational reasoning.

This article explains computational representation as the bridge between problem and procedure. It introduces symbolic representation, data structures, schemas, encodings, records, arrays, lists, trees, graphs, tables, vectors, indexes, state spaces, features, embeddings, compression, metadata, provenance, and representation governance. It emphasizes that algorithms do not operate on reality directly. They operate on representations. Responsible computational reasoning therefore asks not only whether an algorithm works, but whether the representation gives it the right shape of the problem.

Why Representation Matters

Representation matters because algorithms operate on represented structure, not on the world directly. A route planner does not move through a city. It moves through a graph. A search engine does not understand all meaning directly. It works through tokens, indexes, links, embeddings, metadata, and ranking signals. A database does not hold institutional reality itself. It holds tables, fields, keys, constraints, values, and histories. A model does not contain the full system. It contains selected variables, states, parameters, relationships, and assumptions.

The representation determines which operations are possible, efficient, meaningful, or misleading.

Representation is therefore not just a storage choice. It is a reasoning choice.

Back to top ↑

What Computational Representation Means

Computational representation is the process of turning something into a form that a computational system can store, manipulate, search, compare, transform, validate, or reason over. A representation may be symbolic, numerical, structural, graphical, relational, spatial, probabilistic, logical, or learned.

A representation always selects. It includes some features and excludes others. It defines categories, boundaries, formats, types, fields, relationships, and levels of granularity. These choices shape what an algorithm can do.

A representation is successful when it preserves the structure needed for the task without hiding the assumptions that make the representation possible.

Back to top ↑

Representation Before Procedure

Algorithmic reasoning often begins with a question: what procedure should we use? But before procedure comes representation. A problem must be encoded into a form where procedure can act.

The same real-world problem can become different computational problems depending on representation. A city can be represented as a map, a graph, a raster grid, a transportation network, a zoning table, a set of coordinates, a flow model, or a collection of human accessibility constraints. Each representation supports different procedures and hides different features.

A representation can make a problem tractable. It can also make a problem misleadingly narrow. Computational judgment begins by asking whether the representation fits the purpose.

Back to top ↑

What Algorithms Can See

Algorithms only “see” what their representations expose. A sorting algorithm sees orderable elements. A search algorithm sees states and transitions. A classifier sees features. A database query sees rows and fields. A graph algorithm sees nodes, edges, weights, and paths. A neural network sees numerical tensors. A rule engine sees facts and conditions.

This means that missing structure becomes invisible to the procedure.

A computational system can be precise inside its representation while still being incomplete relative to the world.

Back to top ↑

Structure and Operation

Representation and operation are linked. The way information is structured determines which operations are natural. Arrays support indexed access. Stacks support last-in, first-out behavior. Queues support first-in, first-out behavior. Trees support hierarchy and recursion. Graphs support relationship traversal. Hash tables support fast lookup. Vectors support similarity and numerical transformation.

The representation does not merely hold the data. It shapes the imagination of the algorithm.

Back to top ↑

Lists, Tables, Trees, and Graphs

Lists, tables, trees, and graphs are among the most important shapes of computational representation. Each supports a different kind of reasoning.

Lists preserve order. Tables preserve structured records. Trees preserve hierarchy. Graphs preserve relationships. A poor choice among them can make a simple problem hard or a complex problem appear falsely simple.

Representation is often a trade-off between simplicity, expressiveness, efficiency, interpretability, and governance.

Back to top ↑

Schemas, Types, and Constraints

Schemas, types, and constraints define what counts as valid representation. A schema describes fields, relationships, required values, and formats. A type system constrains how values can be used. A database constraint prevents invalid records. A formal specification can define acceptable states and transitions.

These disciplines matter because representation without validation becomes fragile. Invalid values, missing categories, inconsistent units, broken relationships, and ambiguous fields can undermine the entire computational process.

Validation does not guarantee that representation is wise or complete, but it prevents many forms of computational drift.

Back to top ↑

Features, Vectors, and Embeddings

Machine-learning systems often represent objects as features or vectors. A feature is a measurable or encoded property. A vector represents an object as coordinates in a numerical space. An embedding is a learned vector representation designed to capture similarity, context, or structure.

This makes many forms of computation possible: classification, clustering, recommendation, ranking, search, anomaly detection, prediction, and generative modeling. But feature and embedding choices also shape what the model can learn.

Vector representation is powerful because it makes similarity computable. It is risky when similarity is treated as meaning without interpretation.

Back to top ↑

Indexes, Keys, and Retrieval

Indexes and keys shape how information is found. A key identifies a record. An index makes lookup faster. A search index connects queries to documents. A graph index supports traversal. A vector index supports similarity search.

Retrieval is not only about speed. It affects visibility. What can be retrieved can be used. What is hard to retrieve becomes practically absent.

Retrieval structures are epistemic structures. They define what a system can bring back into view.

Back to top ↑

State Spaces and Models

Many algorithms work by representing possible states. A state space contains the configurations a system can occupy. Search, planning, simulation, game playing, optimization, model checking, and reinforcement learning all depend on state representation.

A state representation determines what counts as a possible move, what counts as progress, what counts as failure, and what the algorithm can evaluate.

When a state representation is too narrow, the algorithm may optimize within a world that is not the world that matters.

Back to top ↑

Compression and Loss

Representation often compresses. Compression may be literal, as in reducing file size, or conceptual, as in summarizing a person, place, document, institution, or system into variables. Compression is necessary because computation cannot carry everything. But compression creates loss.

The question is not whether representation loses detail. It almost always does. The question is whether it loses the wrong detail for the task.

A responsible system should explain what was compressed, why it was compressed, and what consequences follow from that loss.

Back to top ↑

Metadata, Provenance, and Traceability

Metadata describes data. Provenance records where data came from and how it changed. Traceability preserves the path from input to transformation to output. These are not optional extras. They are part of responsible representation.

Without metadata, values lose context. Without provenance, outputs cannot be audited. Without traceability, computational evidence cannot be reconstructed.

Representation without provenance invites unearned authority. Traceability keeps computational claims accountable.

Back to top ↑

Representation Risk

Representation risk occurs when a computational representation distorts the problem, hides relevant structure, encodes poor assumptions, or invites overconfident interpretation. This risk is present in databases, models, AI systems, institutional forms, search systems, simulations, dashboards, and decision workflows.

Representation risk is not only a technical issue. It is also an institutional and ethical issue because representations can determine who is visible, who is ignored, and what action appears justified.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

A representation can be described as a mapping from some domain of concern into a computational form:

A loss function can describe what representation fails to preserve:

A feature representation maps cases into vectors:

A graph representation can be written:

A state-space representation can be expressed as:

A representation-quality audit can be summarized as:

These formulas show that representation can be treated as an object of analysis rather than a background assumption.

Back to top ↑

Python Workflow: Representation Audit

The Python workflow below creates a dependency-light audit for representation choices. It scores structural fidelity, operation fit, validation discipline, information loss control, traceability, interpretability, retrieval support, transformation readiness, risk documentation, and governance readiness.

# representation_audit.py
# Dependency-light workflow for evaluating representation choices and computational shape.

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]
TABLES = ARTICLE_ROOT / "outputs" / "tables"
JSON_DIR = ARTICLE_ROOT / "outputs" / "json"


@dataclass(frozen=True)
class RepresentationCase:
    case_name: str
    representation_context: str
    representation_choice: str
    structural_fidelity: float
    operation_fit: float
    validation_discipline: float
    information_loss_control: float
    traceability: float
    interpretability: float
    retrieval_support: float
    transformation_readiness: float
    risk_documentation: float
    governance_readiness: float


def clamp(value: float, low: float = 0.0, high: float = 100.0) -> float:
    return max(low, min(high, value))


def representation_quality(case: RepresentationCase) -> float:
    return clamp(
        100.0 * (
            0.12 * case.structural_fidelity
            + 0.12 * case.operation_fit
            + 0.10 * case.validation_discipline
            + 0.10 * case.information_loss_control
            + 0.10 * case.traceability
            + 0.10 * case.interpretability
            + 0.08 * case.retrieval_support
            + 0.08 * case.transformation_readiness
            + 0.10 * case.risk_documentation
            + 0.10 * case.governance_readiness
        )
    )


def representation_risk(case: RepresentationCase) -> float:
    weak_points = [
        1.0 - case.structural_fidelity,
        1.0 - case.operation_fit,
        1.0 - case.validation_discipline,
        1.0 - case.information_loss_control,
        1.0 - case.traceability,
        1.0 - case.interpretability,
        1.0 - case.risk_documentation,
        1.0 - case.governance_readiness,
    ]
    return clamp(100.0 * mean(weak_points))


def diagnose(quality: float, risk: float) -> str:
    if quality >= 82 and risk <= 22:
        return "strong representation posture with clear structure, operation fit, traceability, and governance"
    if quality >= 68 and risk <= 38:
        return "usable representation posture with review needs"
    if risk >= 55:
        return "high representation risk; structure, fit, loss, or traceability may be unclear"
    return "partial representation posture; strengthen validation, interpretability, risk documentation, or governance"


def build_cases() -> list[RepresentationCase]:
    return [
        RepresentationCase(
            case_name="Route planning graph",
            representation_context="City travel is represented as a weighted graph of intersections and paths.",
            representation_choice="Weighted graph with nodes, edges, travel-time weights, and closure metadata.",
            structural_fidelity=0.86,
            operation_fit=0.90,
            validation_discipline=0.78,
            information_loss_control=0.74,
            traceability=0.78,
            interpretability=0.82,
            retrieval_support=0.84,
            transformation_readiness=0.80,
            risk_documentation=0.76,
            governance_readiness=0.76,
        ),
        RepresentationCase(
            case_name="Institutional records table",
            representation_context="Public-service cases are represented as structured rows and fields.",
            representation_choice="Relational table with keys, statuses, timestamps, controlled vocabulary, and provenance fields.",
            structural_fidelity=0.78,
            operation_fit=0.82,
            validation_discipline=0.86,
            information_loss_control=0.70,
            traceability=0.88,
            interpretability=0.84,
            retrieval_support=0.82,
            transformation_readiness=0.78,
            risk_documentation=0.82,
            governance_readiness=0.86,
        ),
        RepresentationCase(
            case_name="Document embedding index",
            representation_context="Documents are represented as learned vectors for similarity search.",
            representation_choice="Embedding vectors combined with metadata, source records, and retrieval logs.",
            structural_fidelity=0.74,
            operation_fit=0.86,
            validation_discipline=0.72,
            information_loss_control=0.66,
            traceability=0.76,
            interpretability=0.60,
            retrieval_support=0.90,
            transformation_readiness=0.82,
            risk_documentation=0.78,
            governance_readiness=0.80,
        ),
        RepresentationCase(
            case_name="Simulation state model",
            representation_context="A dynamic system is represented with states, transitions, parameters, and assumptions.",
            representation_choice="State-space model with explicit variables, transition rules, parameter records, and scenario metadata.",
            structural_fidelity=0.82,
            operation_fit=0.84,
            validation_discipline=0.80,
            information_loss_control=0.78,
            traceability=0.86,
            interpretability=0.78,
            retrieval_support=0.74,
            transformation_readiness=0.84,
            risk_documentation=0.86,
            governance_readiness=0.84,
        ),
    ]


def run_audit() -> list[dict[str, object]]:
    rows: list[dict[str, object]] = []
    for case in build_cases():
        quality = representation_quality(case)
        risk = representation_risk(case)
        rows.append({
            **asdict(case),
            "representation_quality": round(quality, 3),
            "representation_risk": round(risk, 3),
            "diagnostic": diagnose(quality, risk),
        })
    return rows


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    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)
    path.write_text(json.dumps(payload, indent=2, sort_keys=True), encoding="utf-8")


def summarize(rows: list[dict[str, object]]) -> dict[str, object]:
    return {
        "case_count": len(rows),
        "average_representation_quality": round(mean(float(row["representation_quality"]) for row in rows), 3),
        "average_representation_risk": round(mean(float(row["representation_risk"]) for row in rows), 3),
        "highest_quality_case": max(rows, key=lambda row: float(row["representation_quality"]))["case_name"],
        "highest_risk_case": max(rows, key=lambda row: float(row["representation_risk"]))["case_name"],
        "interpretation": "Representation quality depends on structural fidelity, operation fit, validation, information-loss control, traceability, interpretability, retrieval support, transformation readiness, risk documentation, and governance."
    }


def main() -> None:
    rows = run_audit()
    summary = summarize(rows)

    write_csv(TABLES / "representation_audit.csv", rows)
    write_csv(TABLES / "representation_audit_summary.csv", [summary])
    write_json(JSON_DIR / "representation_audit.json", rows)
    write_json(JSON_DIR / "representation_audit_summary.json", summary)

    print("Representation audit complete.")
    print(TABLES / "representation_audit.csv")


if __name__ == "__main__":
    main()

This workflow treats representation as something that can be reviewed, scored, documented, and governed rather than assumed.

Back to top ↑

R Workflow: Representation Quality Summary

The R workflow reads the Python-generated audit table and creates summary outputs and visualizations using base R. It compares representation quality and representation risk across synthetic systems.

# representation_summary.R
# Base R workflow for summarizing representation choices and computational shape.

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()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

if (!dir.exists(tables_dir)) {
  dir.create(tables_dir, recursive = TRUE)
}

if (!dir.exists(figures_dir)) {
  dir.create(figures_dir, recursive = TRUE)
}

input_path <- file.path(tables_dir, "representation_audit.csv")

if (!file.exists(input_path)) {
  stop(paste("Missing", input_path, "Run the Python workflow first."))
}

data <- read.csv(input_path, stringsAsFactors = FALSE)

summary_table <- data.frame(
  case_count = nrow(data),
  average_representation_quality = mean(data$representation_quality),
  average_representation_risk = mean(data$representation_risk),
  highest_quality_case = data$case_name[which.max(data$representation_quality)],
  highest_risk_case = data$case_name[which.max(data$representation_risk)]
)

write.csv(
  summary_table,
  file.path(tables_dir, "r_representation_summary.csv"),
  row.names = FALSE
)

comparison_matrix <- rbind(
  data$representation_quality,
  data$representation_risk
)

colnames(comparison_matrix) <- data$case_name
rownames(comparison_matrix) <- c("Representation quality", "Representation risk")

png(
  file.path(figures_dir, "representation_quality_vs_risk.png"),
  width = 1400,
  height = 800
)

barplot(
  comparison_matrix,
  beside = TRUE,
  las = 2,
  ylim = c(0, 100),
  ylab = "Score",
  main = "Representation Quality vs. Representation Risk"
)

legend(
  "topleft",
  legend = rownames(comparison_matrix),
  pch = 15,
  bty = "n"
)

grid()
dev.off()

png(
  file.path(figures_dir, "representation_dimensions.png"),
  width = 1400,
  height = 800
)

dimension_means <- colMeans(data[, c(
  "structural_fidelity",
  "operation_fit",
  "validation_discipline",
  "information_loss_control",
  "traceability",
  "interpretability",
  "retrieval_support",
  "transformation_readiness",
  "risk_documentation",
  "governance_readiness"
)]) * 100

barplot(
  dimension_means,
  las = 2,
  ylim = c(0, 100),
  ylab = "Average score",
  main = "Average Representation Evidence by Dimension"
)

grid()
dev.off()

print(summary_table)

This workflow helps compare graphs, tables, embeddings, indexes, schemas, and state models by how well they preserve structure, support operations, and remain traceable.

Back to top ↑

GitHub Repository

The companion repository for this article will provide reproducible code, synthetic datasets, workflow documentation, generated outputs, and representation diagnostics that extend the article into executable examples.

articles/representation-and-the-shape-of-computation/
├── python/
│   ├── representation_audit.py
│   ├── data_structure_shape_examples.py
│   ├── schema_validation_examples.py
│   ├── graph_representation_examples.py
│   ├── vector_representation_examples.py
│   ├── calculators/
│   │   ├── representation_quality_calculator.py
│   │   └── representation_risk_calculator.py
│   └── tests/
├── r/
│   ├── representation_summary.R
│   ├── representation_quality_visualization.R
│   └── representation_risk_report.R
├── julia/
│   ├── representation_transform_examples.jl
│   └── graph_vector_shape_examples.jl
├── sql/
│   ├── schema_representation_cases.sql
│   ├── schema_metadata_provenance.sql
│   └── representation_queries.sql
├── haskell/
│   ├── RepresentationTypes.hs
│   ├── ShapeOfComputation.hs
│   └── Main.hs
├── rust/
│   └── src/
├── go/
│   └── main.go
├── c/
│   └── representation_audit.c
├── cpp/
│   └── representation_audit.cpp
├── fortran/
│   └── representation_quality_model.f90
├── java/
│   └── src/main/java/org/contentcatalyst/algorithms/
├── typescript/
│   └── src/
├── prolog/
│   └── representation_rules.pl
├── racket/
│   └── representation_interpreter.rkt
├── docs/
│   ├── methodology.md
│   ├── article-notes.md
│   ├── representation-and-the-shape-of-computation.md
│   ├── governance-notes.md
│   └── responsible-use.md
├── data/
│   └── synthetic_representation_cases.csv
├── outputs/
│   ├── tables/
│   ├── figures/
│   ├── json/
│   ├── logs/
│   └── reports/
├── notebooks/
│   └── representation_and_the_shape_of_computation_walkthrough.ipynb
├── canvas/
│   ├── canvas_manifest.json
│   ├── canvas_cards.json
│   └── canvas_index.md
└── shared/
    ├── schemas/
    ├── templates/
    ├── taxonomies/
    ├── benchmarks/
    └── governance/

Back to top ↑

A Practical Method for Representation Review

A practical representation review asks whether the computational form fits the problem, the procedure, and the intended use. The goal is not to find a perfect representation. The goal is to make representational trade-offs explicit.

Representation review should happen before optimization. Optimizing the wrong representation can produce precise but misleading results.

Back to top ↑

Common Pitfalls

A common pitfall is treating representation as a technical detail rather than a reasoning decision. The table, graph, vector, schema, feature set, or index may seem like infrastructure, but it determines what the algorithm can know.

Another pitfall is assuming that more data solves representational problems. More data in a poor representation can make the problem larger without making it clearer.

Common pitfalls include:

• wrong shape: using a table where a graph is needed, or a hierarchy where relationships are networked;
• field overconfidence: treating recorded fields as complete descriptions of reality;
• missing context: storing values without source, time, uncertainty, or transformation history;
• flattening relationships: turning complex social, institutional, or system relationships into isolated attributes;
• feature bias: using measurable proxies that distort the concept being modeled;
• embedding opacity: relying on vector similarity without explaining what similarity means;
• schema drift: allowing categories, fields, or meanings to change without versioning;
• retrieval bias: assuming what is easy to retrieve is what matters most;
• compression loss: hiding important variation through aggregation or summarization;
• optimization before representation review: improving speed or accuracy inside the wrong computational form.

The remedy is not representation perfection. It is representation honesty: state what the system can see, what it cannot see, and how that shapes computation.

Back to top ↑

Why the Shape of Representation Shapes Computation

Representation shapes computation because it defines the world available to the algorithm. It determines what counts as an object, a relation, a state, a feature, a value, a path, a record, a similarity, a constraint, an output, or an error. The algorithm then works inside that shape.

This is why computational reasoning cannot begin with procedure alone. It must begin with representation. A powerful algorithm applied to a weak representation can produce fast confusion. A simple algorithm applied to a well-chosen representation can reveal structure clearly.

Representation is therefore one of the most important forms of computational judgment. It is where abstraction, data structure, meaning, efficiency, interpretation, and governance meet. To reason responsibly about algorithms, we must ask not only what procedure is being used, but what form of the world that procedure has been given.

Back to top ↑

Related Articles

• Formal Languages and Symbolic Representation
• Proof, Correctness, and Algorithmic Verification
• Lambda Calculus, Functions, and Formal Computation
• Formal Methods and Machine-Checked Reasoning
• Data Structures as Thinking Tools
• Arrays, Lists, Stacks, and Queues
• Trees, Hierarchies, and Recursive Structure
• Graphs, Networks, and Computational Relationships
• Metadata, Provenance, and Computational Traceability

Further Reading

• Abelson, H. and Sussman, G.J. (1996) Structure and Interpretation of Computer Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: MIT Press.
• Aho, A.V., Hopcroft, J.E. and Ullman, J.D. (1983) Data Structures and Algorithms. Reading, MA: Addison-Wesley.
• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: MIT Press.
• Date, C.J. (2003) An Introduction to Database Systems. 8th edn. Boston, MA: Addison-Wesley.
• Floridi, L. (2011) The Philosophy of Information. Oxford: Oxford University Press. Available at: Oxford Academic.
• Knuth, D.E. (1997) The Art of Computer Programming, Volume 1: Fundamental Algorithms. 3rd edn. Boston, MA: Addison-Wesley.
• Liskov, B. and Guttag, J. (2000) Program Development in Java: Abstraction, Specification, and Object-Oriented Design. Boston, MA: Addison-Wesley.
• Pierce, B.C. (2002) Types and Programming Languages. Cambridge, MA: MIT Press. Available at: MIT Press.
• Ramakrishnan, R. and Gehrke, J. (2003) Database Management Systems. 3rd edn. New York: McGraw-Hill.
• Sedgewick, R. and Wayne, K. (2011) Algorithms. 4th edn. Boston, MA: Addison-Wesley. Companion materials available at: Princeton Algorithms.
• Shannon, C.E. (1948) ‘A mathematical theory of communication’, Bell System Technical Journal, 27(3), pp. 379–423; 27(4), pp. 623–656. Available at: Harvard-hosted PDF.
• Wirth, N. (1976) Algorithms + Data Structures = Programs. Englewood Cliffs, NJ: Prentice-Hall.

References

• Abelson, H. and Sussman, G.J. (1996) Structure and Interpretation of Computer Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262510875/structure-and-interpretation-of-computer-programs/.
• Aho, A.V., Hopcroft, J.E. and Ullman, J.D. (1983) Data Structures and Algorithms. Reading, MA: Addison-Wesley.
• 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/.
• Date, C.J. (2003) An Introduction to Database Systems. 8th edn. Boston, MA: Addison-Wesley.
• Floridi, L. (2011) The Philosophy of Information. Oxford: Oxford University Press. Available at: https://academic.oup.com/book/3251.
• Knuth, D.E. (1997) The Art of Computer Programming, Volume 1: Fundamental Algorithms. 3rd edn. Boston, MA: Addison-Wesley.
• Liskov, B. and Guttag, J. (2000) Program Development in Java: Abstraction, Specification, and Object-Oriented Design. Boston, MA: Addison-Wesley.
• Pierce, B.C. (2002) Types and Programming Languages. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262162098/types-and-programming-languages/.
• Ramakrishnan, R. and Gehrke, J. (2003) Database Management Systems. 3rd edn. New York: McGraw-Hill.
• Sedgewick, R. and Wayne, K. (2011) Algorithms. 4th edn. Boston, MA: Addison-Wesley. Companion materials available at: https://algs4.cs.princeton.edu/home/.
• Shannon, C.E. (1948) ‘A mathematical theory of communication’, Bell System Technical Journal, 27(3), pp. 379–423; 27(4), pp. 623–656. Available at: https://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/entropy.pdf.
• Wirth, N. (1976) Algorithms + Data Structures = Programs. Englewood Cliffs, NJ: Prentice-Hall.

Back to top ↑