PYTHON · NUMPY

The honest joules

Given cited per-operation energies, the learner computes an honest end-to-end joule ledger for a ~1e5-param policy and shows the FP32-to-ternary energy speedup is ~tens x (not ~1000x) because memory movement — not arithmetic — dominates once the multiplies are deleted.

01Challenge

The multiply is dead — you deleted every one of them in module 1. So the energy win must be astronomical, right? Wrong, and knowing exactly why is what separates a frontier engineer from a hype merchant. In this lesson you build the HONEST joule ledger, count what is actually left after the multiplies are gone, and watch a new enemy take the throne. That enemy is the whole reason the frontier answer is what it is.

Predict firstYou just deleted 100% of the multiplies (0 of them remain) and the weights are ~20x smaller. Is the end-to-end energy win therefore around 1000x?

02Model

Here is the discipline the field usually skips. In module 1 we killed the multiply — three states {-1,0,+1} turn a 3.7 pJ FP32 multiply into a 0.03 pJ add, and pack a 32-bit weight toward 1.58 bits (log2 of 3), a ~20x storage density. A triumphalist stops there and shouts 1000x. We do not. Build the ledger honestly with Horowitz's own 2014 numbers and a brutal fact appears: fetching a weight from SRAM costs 5 pJ, and even after you delete the multiply, moving the operand still costs money. Bill that read at a conservative 2-bit-per-trit packing — 16 trits per word, not the best-case 20 — and the ternary arithmetic collapses to 3000 pJ while the memory reads sit at 31250 pJ. Memory is now ~10x the compute. The end-to-end win is a real, defensible ~28x, not a fantasy. And THAT is the frontier argument, not a disappointment: the honest ledger is a compass. It points its needle straight at the term that now dominates — data movement — and says the next order of magnitude does not live in the arithmetic at all. It lives in killing the von Neumann round trip: in-memory compute, the end-to-end trit, where the storage and the adder are the same silicon. Ternary is what makes that jump reachable while staying classical and drop-in — no quantum, no optics, no all-new stack. The multiplier was the first wall. The memory bus is the next one. We just proved where it is.

03Guided practice

Worked: Start with the FP32 cost of a single MAC. Horowitz says the arithmetic is FP_MUL + FP_ADD = 3.7 + 0.9 = 4.6 pJ. But you cannot compute on a weight you have not fetched — each 32-bit weight costs an SRAM_FP32 = 5.0 pJ read. So even in FP32, memory (5.0) already rivals arithmetic (4.6). Multiply by MACs = 1e5 and the FP32 total is 960000 pJ.

Your turn: Now build the ternary ledger. Delete the multiply — the only arithmetic left is an add/sub, INT_ADD = 0.03 pJ. The weight shrinks from 32 bits toward log2(3) = 1.58 bits, a ~20x theoretical density (weight_ratio = 32/1.58 ≈ 20x). But you bill the read HONESTLY, at a conservative 2-bit-per-trit packing — 16 trits per 32-bit word — so the read drops to 5.0/16 = 0.3125 pJ (not the best-case 5.0/20). Sum them: tern_total = MACs*0.03 + MACs*0.3125 = 34250 pJ. Divide: speedup = 960000 / 34250 ≈ 28x.

Independent: Look at the ternary ledger's two terms — arithmetic 3000 pJ, memory 31250 pJ. Which dominates now? Set mem_bound to the honest answer. This single boolean is the thesis: the multiply is gone, the storage is ~20x smaller, and yet the win is ~28x, not 1000x — because moving bits, not multiplying them, is now the bill.

04Feedback

PASS WHEN The bench prints PASS: mem_bound is True, the ternary memory term (31250 pJ) exceeds the arithmetic term (3000 pJ), and the end-to-end speedup lands at ~28x (inside 10-200x).

If your run fails, check:

FAIL with mem_bound left as None or False? You are asserting arithmetic still dominates. Trace the ternary ledger: arithmetic is MACs x 0.03 = 3000 pJ, but memory is MACs x (5/16) = 31250 pJ — memory is ~10x larger. That is the whole point of this lesson: set mem_bound = True.
speedup outside 10-200 (e.g. a wild 1000x or a tiny 2x)? You broke a ledger term. FP32 must be MACs*(FP_MUL+FP_ADD) + MACs*SRAM_FP32 = 960000 pJ; ternary must be MACs*INT_ADD + MACs*(SRAM_FP32/16) = 34250 pJ. If you dropped the FP32 memory term or forgot to divide the ternary read by 16, the ratio blows up. Restore both memory terms and you land at ~28x.
Used = instead of is, or compared mem_bound to a string? The grade checks `mem_bound is True`. Assign the boolean literal True (not "True", not 1) so the identity check passes.

05Retrieve & space

In the ternary ledger you built, arithmetic costs ~3000 pJ and memory reads cost ~31250 pJ. Explain in one sentence why deleting the multiply did NOT produce a 1000x win, and name the term that now sets the ceiling.
A colleague proposes shrinking weights further from 1.58 bits to 0.8 bits to chase more energy savings. Using the ledger's structure, predict whether that alone moves the end-to-end number much, and say what you would have to change instead to unlock the next order of magnitude.

06Mastery & project

Passing proves you can build an honest end-to-end energy ledger from cited per-op numbers, show that deleting the multiply yields a real but bounded ~tens-x win (not a mythical 1000x), and correctly diagnose that memory movement — not arithmetic — is the dominant term once the multiplies are gone. You can defend the number instead of quoting a slogan.

This is the hinge of the arc. Module 1 killed the multiply; this module's honest ledger proves that win is real but bounded (~tens x) and names the new dominant cost — data movement across the von Neumann bus. That diagnosis is the setup for the next module's frontier answer: in-memory compute and the end-to-end trit, which attack precisely the memory term this ledger exposed. The honest joules are what earn the right to make the post-von-Neumann claim.

GO FURTHER · THE LIVE PLAYGROUND

Drive the live ternary policy ↗ — FP32 vs ternary vs log, trained live
Read the whitepaper ↗ — Multiply-Free Neural Computation (TR-2026-02)

← BitVLA: the trit ships in production Why the multiply-free win is a memory win →

PYTHON · NUMPY

The honest joules

Build the honest joule ledger for a ~1e5-param edge policy using Horowitz's ISSCC-2014 op energies. Fill the two ledgers, compute the end-to-end speedup and the weight-size ratio, then make the one call the frontier turns on: with the multiplies deleted, does memory movement now dominate? Every number here is COMPUTED from cited per-op energies — no invented benchmark, and the memory saving is billed at a conservative practical packing, not a best-case one.

You read

the arrays and values already in scope

You change

the code you write in each cell

Fixed

the dataset and the checks that grade you