Inside the Warehouse

Codex ET-2 holds 2⁶⁴ icons. That is 18,446,744,073,709,551,616 of them. This page explains how they are stored, why similar icons land next to each other on the grid, and what the math is doing under the surface. None of this is required to use the app, but the layout is the point of the piece.

Why 8×8

An icon in Codex ET-2 is an 8×8 monochrome bitmap. Sixty-four pixels. Each pixel is on or off. That gives 2⁶⁴ distinct bitmaps. 64 is the size of one CPU register on every modern phone, which means every icon is a single 64-bit integer in memory. Multiplication, comparison, addressing — all one instruction.

An 8×8 grid is also the smallest size at which a human reliably reads a pattern as a thing. Smaller grids feel like marks; larger grids feel like illustrations. Eight by eight sits where a smiley face still works.

Sixty-four Bits, One Catalog

The simplest catalog assigns icon number n to the bitmap whose 64-bit representation is n. Icon 0 is all zero. Icon 1 has only the top-left pixel on. Icon 2 has only the second pixel on. Icon 18,446,744,073,709,551,615 is all on.

This catalog has a problem. Consecutive icons in the catalog look nothing alike — flipping the lowest bit changes one pixel, but flipping bit 63 changes a completely different pixel. Walking by icon number is jarring. You want similar icons to be neighbors, so that walking the warehouse feels like a smooth journey, and so that small edits to an icon land on a close cell.

We solve this in two steps.

Step One: Gray Code

A Gray code is a way of ordering binary numbers so that successive numbers differ in exactly one bit. The first few entries in a 3-bit Gray code:

000  →  001  →  011  →  010  →  110  →  111  →  101  →  100

Each step flips exactly one bit. Compare that to plain binary, where the step from 011 to 100 flips three bits at once.

In Codex ET-2, we apply a Gray-code transformation to each icon’s 64-bit value before placing it on the grid. The Gray-code property: stepping one position along the sequence flips exactly one bit of the icon. Of an icon’s 64 one-bit neighbors (one per pixel), two sit on the cells immediately adjacent — the previous and next sequence positions. The other 62 are scattered farther along the curve, but always far closer than a random teleport.

This is why pixel editing in the app stays inside a coherent neighborhood. Tap the right pixel and you have walked one cell. Tap any other pixel and you have hopped to another close cell along the curve — still a one-bit edit, still part of the same family of icons.

Step Two: The Hilbert Curve

Gray code gives us a sequence: every icon has a position 0 through 2⁶⁴−1. But the app is a 2D grid, not a number line. We need a way to project that one-dimensional sequence onto a two-dimensional surface without losing the locality property.

This is what a Hilbert curve is for.

A Hilbert curve is a continuous, space-filling curve invented by David Hilbert in 1891. It threads through a 2D grid such that points close together along the curve stay close together in 2D as well. Plain row-major layout (the way a TV reads pixels) destroys locality at the end of every row — pixel 7 and pixel 8 are next to each other in the sequence but at opposite ends of two different rows. A Hilbert curve has no such seam. It snakes through the grid in a fractal pattern where neighbors-on-the-curve are almost always neighbors-in-2D.

We use a 2³² × 2³² grid. That is 4,294,967,296 cells on each axis, exactly 2⁶⁴ cells total. The Hilbert curve maps Gray-code position n to a cell (X, Y) on that grid. Those (X, Y) values are what the app shows you under the focused icon.

What That Means for Walking

Composing the two steps:

The icon’s 64-bit value is Gray-coded into a sequence position.
The sequence position is mapped to a grid cell via the Hilbert curve.
The cell (X, Y) is the icon’s permanent address in the warehouse.

Three consequences fall out:

1-bit edits stay in the neighborhood. An icon has 64 one-bit neighbors — one per pixel. Two sit on the cells directly next to you; the rest are scattered along the curve nearby. Tap a pixel and you teleport to one of those 64 cells. Sometimes it is next door. Sometimes it is a short hop. Always in the same part of the catalog.

The warehouse has neighborhoods. A few cells around any focused icon hold the icons closest to it under tiny edits. Walking around with the d-pad or swipes browses a coherent neighborhood, not a random sample.

Long-distance teleports go a long way. WANDER picks a uniformly random 64-bit value. After Gray code and Hilbert, the resulting cell is almost always billions of cells away from where you were. The camera flies that distance because that distance is real.

No Storage

There is no database of icons inside Codex ET-2. The catalog is implicit. The forward map (icon → coordinate) and the inverse map (coordinate → icon) are both closed-form algorithms that run in microseconds. Given any (X, Y), the app computes the icon at that address on the spot. Given any icon, it computes its address the same way.

This is why sharing works the way it does. The shared image’s filename encodes the (X, Y). The receiver’s app reads that, computes the icon, and lands on the same cell. Nothing was stored on a server. The mathematics is the storage.