And How Digital Circuitality Tells the Truth
Open any programming language on any computer on Earth. Type 0.1 + 0.2. The answer is 0.30000000000000004.
This is not a bug. This is IEEE 754 — the standard that every computer has used for decimal math since 1985. Python, JavaScript, Rust, C++, Java — every language produces this result. And every programmer eventually learns to shrug and "just deal with it."
But what if you are building a flight computer? A medical device? A financial system that handles billions of dollars? "Just deal with it" is not an engineering answer. It is a prayer. And prayers do not belong in production systems.
The Problem Nobody Talks About
When Boeing designs a flight control system, they do not use Python floats. When NASA calculates trajectories, they do not "hope" the rounding works out. When banks process transactions, they do not use double. These organizations know something the rest of the industry ignores.
These systems use fixed-point arithmetic — integers multiplied by a scale factor. Instead of 3.14, they store 3140. Instead of $19.99, they store 1999 cents. No floating point. No rounding surprises. Exact. Every single time.
But here is the problem: this pattern is informal. It is a convention, not a language feature. The programmer has to remember the scale factor, handle the conversions manually, and test obsessively because the language offers zero guarantees. One tired engineer forgets to scale, and a $200 million Mars probe crashes into the surface.
What If the Language Enforced It?
This is exactly what PCD does with Closure Domains. And this is where things get exciting.
In PCD, every variable lives inside a declared domain — a numeric range that defines exactly what values are valid. When you need "decimal" math, you do not use floats. You declare your precision explicitly, and the compiler enforces it:
PC scientific_calculator { // The engineer DECLARES: "I need π with 6 decimal places" domain PI: Range [3141592, 3141593]; // All calculations use integers scaled by 10⁶ // No IEEE 754. No rounding surprises. // Error: ±0.0000005 — KNOWN and DECLARED }
Here is the key insight, and it is profound: π is an irrational number — it has infinite decimals. An infinite value can be rejected when covered by the model in a closed circuit. So the engineer declares which π they need. π with 3 decimals (3141) for a school calculator. π with 15 decimals (3141592653589793) for NASA. The precision IS the domain boundary. The engineer decides. The compiler enforces. No ambiguity. No surprises.
Three Levels of Math in Digital Circuitality
Approach Type Error Certification ───────────────────── ───────────── ───────────────── ───────────── Integer arithmetic U8, I64 Zero — exact closure check passed ✓ Scaled integers I64 + scale Declared closure check passed ✓ Floating point F64 IEEE 754 rounding closure = CONTRACTThe first two give you full certification — closure check passed, supported by bounded evidence. The third gives you convenience at the cost of predictability. You choose. But now, for the first time, you are making an informed choice instead of accepting a hidden compromise.
The Engineer's Mindset
This is the fundamental shift in how you think about software: PCD programmers are not coders. They are circuit engineers.
A coder writes velocity = distance / time and hopes the types work out. Hopes there is no division by zero. Hopes the precision is sufficient. Hopes.
An engineer writes:
domain velocity: Range [0, 900]; // my circuit accepts [0, 900] domain distance: Range [0, 20000]; // bounded input domain time: Range [1, 86400]; // never zero (prevents division by zero) domain scale: Range [1000, 1000]; // 3 decimal places of precision fn calculate_velocity(dist, t) { // dist and t are scaled ×1000 // Result is in [0, 900000] (velocity × scale) return (dist * scale) / t; }
The engineer KNOWS:
The input ranges (declared domains)
The precision (declared scale)
The error tolerance (±0.001 from the scale factor)
That division by zero is outside the declared model (time ≥ 1)
That the circuit closes (closure check passed)
The coder knows none of this. The coder discovers it at 3 AM when production crashes, when the customer calls screaming, when the post-mortem reveals a rounding error that compounded for six months.
review-scoped Math — Any Function, Any Precision
And this goes far beyond basic arithmetic. Logarithms, trigonometry, square roots — all implementable as review-scoped polymers using Taylor series, CORDIC, or Newton's method with only core monomers (ADD, SUB, MUL, DIV). No floating point required:
// ln(x) via Taylor series — all integer arithmetic
// Scale: ×1000000 (6 decimal places)
// ln(2) = 693147 (represents 0.693147) PC certified_ln { domain input: Range [500000, 2000000];
// [0.5, 2.0] × 10⁶ domain output: Range [-693147, 693147];
// ln range × 10⁶
fn ln_scaled(x) {
// Taylor: ln(1+t) = t - t²/2 + t³/3 - t⁴/4 + ...
// Using only ADD, SUB, MUL, DIV (core monomers)
// closure check passed guaranteed } }This is not theoretical. Every bank in the world already does transaction math this way. Every embedded system already does sensor math this way. The difference is that PCD makes it a first-class language feature with automatic compiler verification. What used to be a fragile convention enforced by discipline is now a bounded review evidence enforced by the compiler.
The Circuit Is Closed. The Truth Is Known.
When your program compiles in PCD:
You know the precision of every calculation
You know the error bounds of every result
You know that no value exceeds its declared domain
You know that the behavior is identical on every machine
Your calculator is not lying to you anymore. For the first time in the history of computing, you can trust the math — because the math proves itself.
This is Part 4 of a series. Part 1: What if Software Worked Like DNA? | Part 2: AI Safety with Policy Circuits | Part 3: The BPU — Hardware That Says No
