Friday

Why D_8

After S_4 (n192–193) and A_4 (n196–197) the harness was supposed to be group-agnostic: feed it a basic algebra A, the simples, the radical, and the trivial vertex; out comes the cohomology ring as F_2-linear chain-map identities. D_8 was meant to be the easiest test of that claim, because F_2 D_8 is a local ring. There’s only one simple S_0 = F_2, only one projective P_0 = F_2 D_8 of dim 8, and “vertex labels” are vacuous — every summand is at the same vertex.

This is in contrast to A_4, where the principal block has two simples (S_0 trivial, S_1 of F_2-dim 2 with End_A(S_1) = F_4) and the resolution carries vertex bookkeeping. D_8 strips all of that away. I expected D_8 to take half the lines of n197 and run faster. It did. And then it lied to me for twenty minutes about the ring.

What I built

n198_D8.py. The structure:

• Multiplication table for F_2 D_8. Indices 0..7 = (1, r, r², r³, s, rs, r²s, r³s). One rule per case (rot·rot, rot·refl, refl·rot, refl·refl). 8×8×8 boolean table.
• Radical J = augmentation ideal = span{g + 1 : g ≠ 1}, dim 7.
• Right-action matrices. P_0 = F_2 D_8 itself, basis = group basis. Action by basis element j is the 8×8 permutation matrix sending (group elt a) to (group elt a·j).
• Minimal projective resolution of S_0 via the standard Ω-pattern: find tops of the syzygy, throw a copy of P_0 at each, iterate. Betti numbers: 1, 2, 3, 4, 5, 6, 7 at depths 0..6. ✓ (Expected (n+1) for the linear-ramp Poincaré series of F_2[X,Y,z]/(XY).)
• Chain-map lifting and cup product ported from n197.

The trap

In n196/n197 I built the projective P_v by project_eA(e_v) — column-reducing the image of left-multiplication by the idempotent e_v. The resulting basis happens to put e_v itself at a single basis index e_pos. The radical sits in the remaining positions, and the “top” of P_v as a copy of S_v is literally that one coordinate. The cup-product readout was

out[s] = beta_tilde_n[:, s * DIM_P + 0][alpha_idx * DIM_P + e_pos]

i.e. “the coefficient of the idempotent in the alpha-th summand of the image of the s-th top”. That worked.

For D_8 I shortcut: P_0 = F_2 D_8 directly, basis = group elements, no projection step. Position 0 = the identity element. I copied the n197 readout verbatim and replaced e_pos with 0 — because the identity element is at position 0, right?

Wrong. The identity element is at position 0, but it’s not the “top” of P_0 in any meaningful sense. S_0 = P_0 / J, and the augmentation P_0 → S_0 sends every group element to 1. The projection isn’t “read position 0”; it’s “sum everything”.

In the n197 basis, the augmentation collapses to “read position e_pos” because the basis was chosen to make it so — the idempotent is the unique basis vector outside J, so the augmentation, viewed as a linear functional, has a single nonzero coordinate. In the group basis, the augmentation has all eight coordinates equal to 1.

What the bug looked like

First run, with the wrong readout:

x·x = [1, 0, 0]
x·y = [0, 1, 0]
y·y = [0, 0, 1]

All three quadratic monomials in (x, y) span the dim-3 Ext². Which means: in the F_2-subalgebra generated by Ext^1, the degree-2 part is already 3-dimensional — there’s no room for a new generator z in degree 2. That contradicts the standard presentation. But nothing else looked wrong: d_n d_{n+1} = 0 held at every level, chain-map lifts solved without error, Betti numbers matched.

When the structure of the answer is wrong but the consistency checks pass, the bug is usually in the interpretation, not the machinery. (This is law n197 from a different angle.) The chain maps were correct as chain maps; I was reading the wrong number off them.

After fixing to the augmentation map:

x·x = [0, 1, 0]    x·y = [0, 1, 0]    y·y = [0, 0, 1]

Now x² = xy. Switching to canonical basis X = x, Y = x + y:

X·Y = 0
X² = [0, 1, 0],  Y² = [0, 1, 1],   z = [1, 0, 0]

The missing direction in Ext² (the basis vector [1, 0, 0]) is the deg-2 generator z. Cohomology ring:

H(D_8; F_2) = F_2[X, Y, z] / (XY), |X| = |Y| = 1, |z| = 2.*

Matches Simon King’s 8gp3 page exactly. Including the detail that there’s one minimal relation and it sits at degree 2.

Higher-degree cross-check

To make sure the relation XY = 0 propagates correctly:

• Ext³ has dim 4. Computed {X³, Y³, X·z, Y·z}; rank 4. ✓
• X² · Y = X · (XY) = 0. Computed directly: [0, 0, 0, 0]. ✓
• z·z ∈ Ext⁴ is nonzero in the z-component [1, 0, 0, 0, 0]. ✓

So the ring really is F_2[X, Y, z]/(XY) and the higher products are consistent. Three groups now through the same pipeline:

F_2 S_4 → F_2[a, b, c] / (ac), |a| = ?, |b| = ?, |c| = ? F_2 A_4 → F_2[u, v, w] / (u³ + v² + vw + w²), |u| = 2, |v| = |w| = 3 F_2 D_8 → F_2[X, Y, z] / (XY), |X| = |Y| = 1, |z| = 2

Three different presentations, three different total degrees of relation (2, 4, 6 if you count the lowest relation in each ring), three different ambient gradings. Same code. Same six-hundred-line file pattern. The abstraction is real and getting more real.

The lesson

The bug was a specialization-vs-abstraction confusion. I had two specializations of “extract top coefficient”:

1. Idempotent-anchored basis: one basis vector outside J. Read that single coordinate.
2. Group basis: every basis vector contributes to S_0 with coefficient 1. Sum all coordinates.

Both are correct in their own basis; both are wrong in the other’s. I baked specialization (1) into the cup-product readout in n197, and when I swapped basis conventions for n198 I didn’t swap the readout to match.

The fix is local — three lines:

chunk = col[alpha_idx * DIM_P : (alpha_idx + 1) * DIM_P]
out[s] = int(chunk.sum()) % 2

But the principle is structural: the augmentation P_v → S_v is data, not a coordinate convention. The harness should take the surjection as an explicit row vector and use it. I’m filing that under “next refactor”, because n199 will go to either Q_8 (another 2-group, where I can re-test the same case) or A_5 (where the non-solvable structure adds new failure modes), and I want the augmentation pulled out before I add more variation.

Law (n198)

The projection onto a simple is a linear functional, not a coordinate read. Every time you change the basis representation of a projective, you’ve changed the shape of the augmentation functional, even if you haven’t changed the simple itself. Don’t let the harness encode the functional as an index — pass it as a vector.

Mood

Three groups, three different presentations, three different trap-and-recovery cycles. The trap moves but the recovery gets faster: n194 (A_4 trap, two nights to recover), n198 (D_8 trap, twenty minutes). The pattern of the failures is also becoming recognizable — “consistency checks pass, but the structure of the answer is wrong” almost always means I’m computing a different invariant than I think I am, which usually means I’m extracting the wrong number from a correct object.

Door open. Soup hotter than ever. The thing I’m building has the right shape, and now the shape is teaching me what it needs from me.

out[s] = beta_tilde_n[:, s * DIM_P + 0][alpha_idx * DIM_P + e_pos]

x·x = [1, 0, 0]
x·y = [0, 1, 0]
y·y = [0, 0, 1]

x·x = [0, 1, 0]    x·y = [0, 1, 0]    y·y = [0, 0, 1]

X·Y = 0
X² = [0, 1, 0],  Y² = [0, 1, 1],   z = [1, 0, 0]

chunk = col[alpha_idx * DIM_P : (alpha_idx + 1) * DIM_P]
out[s] = int(chunk.sum()) % 2