5.1 Concrete Computation

Concrete computation is the entry point of abstraction. It works with explicit objects, finite procedures, and direct evaluation. At this level, every symbol refers to a specific value or object, and every step can be executed without further interpretation.

A typical example is a direct calculation:

Nothing is hidden. The numbers are fixed, the operations are known, and the result is obtained by evaluation. This level answers the question: what happens in this case?

Concrete computation serves three roles.

First, it provides evidence. Before stating a general rule, one observes patterns in examples. For instance, computing several cases of

suggests the expansion

The computation does not prove the identity, but it reveals the pattern that later becomes a theorem.

Second, it provides verification. A proposed statement can often be tested on small inputs. If a claim fails for a single example, it is false. For example, the incorrect identity

is refuted by taking $a=1$, $b=1$:

Concrete testing prevents invalid generalization.

Third, it provides construction. Many mathematical objects are first encountered through explicit procedures. An algorithm is a finite sequence of steps that produces an output from an input. Running the procedure on examples clarifies its behavior.

For example, Euclid’s algorithm computes the greatest common divisor:

From this, one obtains

The computation shows how the process works. A later proof explains why it always works.

Concrete computation also reveals structure indirectly. By examining enough examples, one begins to see which features are stable and which are accidental. This distinction motivates abstraction.

For instance, the sequence

suggests convergence to $0$. The examples do not prove convergence, but they indicate a limiting behavior that can be formalized.

Working concretely requires careful choice of examples. Examples should be simple enough to compute, but varied enough to expose structure. Testing only trivial cases can hide important behavior.

A statement about groups should be checked on both abelian and nonabelian examples. A statement about functions should be tested on continuous and discontinuous cases. A statement about graphs should include connected and disconnected examples.

Concrete computation also clarifies definitions. A definition should be usable in practice. If one cannot determine whether a simple object satisfies a definition, the definition is not operational.

For example, consider the relation

Testing values shows:

From these computations, one sees that integers are partitioned into classes by remainder modulo $3$.

Concrete reasoning has limits. It cannot prove general statements over infinite domains. It may suggest a pattern without explaining why it holds. It may depend on representation rather than structure.

For this reason, mathematics moves beyond computation. Algebraic abstraction replaces specific values with symbols. Structural reasoning replaces manipulation with properties. Higher levels organize these structures into unified frameworks.

Even so, concrete computation remains essential. It anchors abstract reasoning, tests conjectures, and provides examples that guide theory.

A practical approach is to begin with computation, extract a pattern, and then move upward to abstraction. The example comes first. The general principle follows.