0.1 + 0.2 = 0.30000000000000004. We Fixed That.

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 cannot exist 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       Φ_c = 1 ✓
Scaled integers        I64 + scale    Declared           Φ_c = 1 ✓
Floating point         F64            IEEE 754 rounding  Φ_c = CONTRACT

The first two give you full certification — Φ_c = 1, mathematically proven. 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 impossible (time ≥ 1)

That the circuit closes (Φ_c = 1)

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.

Certified Math — Any Function, Any Precision

And this goes far beyond basic arithmetic. Logarithms, trigonometry, square roots — all implementable as certified 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)
        // Φ_c = 1 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 mathematical guarantee 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