Numbers as Machines

Classical numerics treats numbers as values — static objects stored in registers, manipulated by arithmetic circuits, approximated by floating-point hardware. This essay proposes a different substrate: every number is a deterministic, forkable virtual machine that emits an infinite digit stream on demand.

This is not a metaphor. It is a literal computational ontology with precise consequences for implementation, memory complexity, and the structure of mathematics itself. The framing has deep roots — Cauchy sequences, computable reals (Turing 1936), coalgebraic stream arithmetic, p-adic expansions, exact real arithmetic systems like iRRAM, and the Type-2 Theory of Effectivity all instantiate parts of this idea. What is new here is not the underlying mathematics but the unified protocol, the codec/base separation, and the explicit ABI that makes all of it composable at native speed.

The primitive is simple. A number is any deterministic program that implements this interface. Everything else — vectors, matrices, tensors, p-adics, transcendentals, metrics, arithmetic — is a combinator over this primitive.

step : State → (digit, State)

A vector is a nesting of binary multiplexer encoders. A matrix or tensor is a nesting of vector construction operators. This is not an analogy to existing data structures — it is the correct ontological description of what these objects are.

MUX(selector, left, right)

Where selector is itself a generator, and left and right are generators recursively.

Arithmetic becomes generator composition. Addition is a carry-propagating combinator over two digit generators. Multiplication is a convolution combinator. Division, negation, and subtraction follow the same pattern — pure generator composition.

Standard positional arithmetic has a notorious flaw as a stream operation: addition is not local. The first digit of 0.4999... + 0.5000... cannot be determined from any finite prefix — a carry from arbitrarily deep in the expansion could propagate up and flip every digit above it.

Any naive digit-by-digit addition combinator will fail to terminate on inputs near a digit boundary. This is not an edge case; it is a structural property of the standard representation.

• ✓ Addition is digit-local — no unbounded carry propagation
• ✓ Each number has multiple valid encodings (the redundancy)
• ✓ The MUX/codec layer projects to standard non-redundant form only when emitting an externally visible digit

Because digits are computed on demand and the tree is lazily evaluated, unbounded precision is not a feature to be added — it is the default behavior of the substrate. Structural sharing keeps memory bounded to what is actually needed.

You compute exactly as many digits as the consumer requests, and no more. This is the same mechanism used by lazy streams in functional languages and exact real arithmetic libraries (iRRAM, Haskell's Data.Number.CReal, MPFR with rigorous error tracking), but grounded in a more explicit state-machine semantics that LLVM can compile directly to native code, and unified under a single ABI rather than scattered across domain-specific libraries.

The p-adic numbers are particularly natural in this model, and notably easier than the reals in a precise technical sense: digit commitment is local in p-adics, where it is non-local in the reals.

A p-adic number is a digit stream indexed from the least significant digit upward, with digits in {0, 1, ..., p-1}. In the generator model, this is simply a MUX tree with a p-way multiplexer instead of a binary one.

This has an immediate consequence: the p-adic metric is also a periodic state machine. The p-adic distance between two numbers x and y is p^{-v_p(x-y)}, where v_p(x-y) is the index of the first digit where they differ. If both are periodic generators, then the metric computation is a product automaton over their state spaces — itself a finite, periodic machine.

Supporting most of mathematics requires some nonstandard primitives — operators that compile mathematical definitions into digit streams with correctness guarantees.

series_step(state) → (term, new_state)

tail_bound(state) → E

refine_interval(L, U, term, E) → (L', U')
emit_digit_if_safe(L, U, base) → maybe digit

valuation(a_n) → v_p(a_n)

carry(k) → {0, 1, ...}

compose(f, g) → h

memo(generator) → generator'

The full picture of a number in this model is a forkable, coinductive, deterministic nano-VM.

1. Stateful Each number carries internal state that evolves as digits are requested.
2. Forkable The state can be cloned exactly at any point, enabling parallel digit computation, comparison, metric evaluation, and speculative arithmetic.
3. Deterministic & Pure Forking is exact; there is no hidden global state.
4. Periodic-Friendly The VM supports periodic state cycles, ultimately periodic orbits, and product automata.
5. Composable Two VMs combine into a new VM via arithmetic and analytic combinators.
6. Lazy Digits are produced on demand, not precomputed.

// Automaton tier: pure value semantics, O(1) fork
typedef struct {
    uint32_t base;
    uint32_t phase;
    uint64_t state[4];     // sufficient for degree-4 algebraic
} AutomatonVM;

// Series tier: explicit deep-copy required for fork
typedef struct {
    uint32_t base;
    uint32_t index;
    const SeriesSpec *spec;     // immutable, safe to alias
    ArbitraryInt *accum;        // mutable, deep-copy on fork
    ArbitraryInt *error_bound;  // mutable, deep-copy on fork
} SeriesVM;

The nano-VM is not a bytecode interpreter. It does not encode or decode its own state. That is precisely why LLVM is the right implementation target.

struct NumVMStep {
    uint32_t digit;
    AutomatonVM next;
};

typedef struct NumVMStep (*NumVMFn)(AutomatonVM);

%AutomatonVM = type { i32, i32, [4 x i64] }
%NumVMStep   = type { i32, %AutomatonVM }

define %NumVMStep @num_step(%AutomatonVM %s) { ... }

static inline AutomatonVM num_vm_fork(AutomatonVM s) {
    return s; // pure value copy — no hidden state
}

The base parameter is not a mathematical constant. It is a projection operator — a codec. This is the correct ontological description.

This is the same relationship as a probability distribution to an arithmetic coder, a message to a bitstream, a model to a codebook. Base is a codec. The number is the generator. The digits are the encoded tape.

In this model, ℝ is not the ontology. ℝ is one possible projection of the generator. The generator is the real object. The real number is the encoding. Changing base is changing coordinate charts on generator space — the underlying object does not change, only the representation does.

The Bailey-Borwein-Plouffe formula for π in base 16 allows computing the n-th hexadecimal digit of π without computing the preceding digits. The generator-VM model contributes a first-class library primitive that lifts this phenomenon out of one-off optimizations and into the ABI.

In base 16, the π-generator VM has a periodic sub-automaton. The codec (base 16) aligns with that periodic structure, exposing a fast-forward opcode. In base 10, the same automaton has no such periodic orbit under that codec. No fast-forward is possible.

skip(n, state) → state'

Available only when the automaton has a periodic orbit under the current codec. This is the computational form of a BBP formula. The skip function cannot be synthesized automatically — it requires per-constant manual derivation — but once written, it becomes a first-class operation that LLVM optimizes alongside the rest of the generator graph.

Runtime is elastic — you can trade time for algorithms, parallelize, precompute. Memory (state size) is structural. It is tied to the Kolmogorov complexity of the number and to the order and dimension of the recurrence or automaton.

In the nano-VM model, the memory cost of a number is the size of its VM state — specifically, the number of independent fields and the bit-width required for each.

π and e are not just "more complicated" than √2 in some informal sense. They appear to be the first two members of an ascending sequence of irreducible generator-complexity classes, each requiring genuinely more state to maintain correctness over an unbounded digit stream.

In this ontology, randomness does not exist as a fundamental phenomenon. Every number is a deterministic generator VM. What people call "random" is a number whose generator is inaccessible — not absent, not large, but hidden.

In this ontology, a random program is a perfectly valid number — not metaphorically, but literally. Any program that has a finite state representation, implements step(state) → (digit, next_state), and does not halt, is a number.

The space of numbers, as the library exposes it, is the space of all possible infinite computations. This is the most general possible operational number ontology — a strict superset of all existing computational frameworks.

There is a Futurama line that captures the situation with uncomfortable precision. Professor Farnsworth, having "translated" an alien message, announces: "Of course we can translate it — but only into Betacrypt-3… a language so complex, there is even less chance of understanding it." The joke lands because the translation technically succeeds — it just maps the problem into a representation where the operations people actually cared about have become harder, not easier. This is, structurally, exactly the move Numbers as Machines makes. We "translate" every number into a generator-VM that emits an infinite digit stream, gaining uniformity, composability, and exactness. The bill for that translation comes due precisely here: the very act of representing a number as a non-halting machine is what makes "is this equal?" and "which is bigger?" non-primitive, partial, or outright undecidable. We did not make the substrate too complex out of carelessness — the translation preserves computability by discarding cheap equality. Betacrypt-3, but the trade is honest and the dialect is at least the same one everywhere.

The natural equivalence relation on generator VMs is extensional: two VMs are equal iff they produce identical digit streams on every query. This relation is not computably decidable — it is the canonical example of an undecidable semantic property of programs (Rice's theorem).

What it ships instead is a family of interval-based and bounded-precision predicates:

bool definitely_less_than(VM x, VM y);          // true / false / pending
bool agrees_with(VM x, VM y, int digits);       // exact for a finite prefix
Trit compare(VM x, VM y, int max_digits);       // Less | Greater | Indistinguishable

A substrate is not a library. The ABI is the foundation, but users interact with a stratified API that hides the substrate where appropriate and exposes it where necessary.

# Precision context — establishes target accuracy for a region of code
with precision_context(digits=50):
    result = sin(pi / 4) + sqrt(2)

# Explicit comparison — interval-honest, never lies about decidability
x.agrees_with(y, digits=20)        # bool
x.definitely_less_than(y)          # True | False | Unknown

# Explicit memoization policy — no hidden caches
x = sqrt(2).cached(max_digits=1000)
x = pi.streaming()                  # O(1) space, sequential only

# Forking with honest cost annotation
x1, x2 = pi.fork()                  # O(log n) for series-tier VMs

# Skip-ahead when available
digit_billion = pi.in_base(16).skip(10**9).next_digit()

The architecture admits a staged build, with each phase delivering value and informing the next.