Each Problem in this Campaign is one frontier cell of the Matrix
Multiplication Catalog (solven-eu/matmulcatalog): a canonical shape ⟨n,m,p⟩
(C = A·B with A n×m, B m×p) and an algebraic setting. Read the Problem's
frontier reference input first: it holds the exact shape, setting, the
current frontier rank and additions, every witness scheme at that rank, the
pinned source commit and links to the witness files.
Rank first, additions second (the catalog's own discipline). The score is the rank of your verified scheme; lower is better; the benchmark baseline is the catalog frontier. A rank tie with fewer flat additions (nz(U)+nz(V)+nz(W) − 2·rank − n·p) is recorded in the evidence as an additions improvement but does not change the score.
| setting | coefficients | identity checked |
|---|---|---|
| F2 | rationals with odd denominators, reduced mod 2 | in GF(2) |
| F3 | rationals with denominators coprime to 3, reduced mod 3 | in GF(3) |
| Z | integers | exactly over Z |
| Q | rationals (numbers or strings such as "1/2") |
exactly over Q (equivalently R: no JSON coefficient separates them) |
| C | Gaussian rationals [re, im] |
exactly over Q(i) |
| comm | rationals, bilinear or non-bilinear | exactly, assuming the entries of A and B commute |
Prefer exact coefficients (integers, "1/2" strings). A decimal that is not
within 1e-9 of a rational with denominator ≤ 1024 is treated as an inexact
floating-point coefficient: it is refused for F2/F3/Z, and for Q, C and comm
the scheme is judged by the catalog's own epsilon rule (Frobenius residual of
the trilinear identity below 1e-9, Verifier.isExactComplex) instead of the
symbolic check; the evidence says which path ran.
A scheme valid over Z is valid over every setting; a scheme valid over Q is valid over F_p only when its denominators are invertible mod p, and then only if the identity still holds mod p. Non-commutative (bilinear) schemes are valid commutative schemes; the reverse is false.
SchemeIO conventions)Dense form:
{"n": [2, 2, 2], "m": 7,
"u": [[1,0,0,1], ...], // m rows, each n·m entries: coefficient of A[i][j] at position i*m + j (row-major)
"v": [[1,0,0,1], ...], // m rows, each m·p entries: coefficient of B[j][l] at position j*p + l (row-major)
"w": [[1,0,0,1], ...]} // m rows, each n·p entries: C[i][l] at position l*n + i (COLUMN-major, dronperminov convention)
Product k is (Σ u[k][a]·A[a]) · (Σ v[k][b]·B[b]); C[c] = Σ_k w[k][c]·product_k.
Note the column-major flatten of w: for ⟨n,m,p⟩ the C entry (i,l) sits at
l*n + i. Any axis orientation of the shape is accepted (submit n as the
actual orientation of your scheme).
Sparse form (u_sparse/v_sparse/w_sparse, row-oriented map keyed by the
product index, positions as above):
"u_sparse": {"0": {"i": [0, 3], "c": [1, 1]}, "1": {"i": [2, 3], "c": [1, 1]}, ...}
Perminov "reduced" files (u/v/w as lists of {index, value} with
optional u_fresh/v_fresh/w_fresh) and complex files ("fields": ["C"],
entries as [re, im]) are also accepted. For the comm setting a
non-bilinear scheme is
{"n": [1, 2, 1], "scheme_type": "non_bilinear", "rank": 3,
"u_a": [[[0, 1]], ...], "u_b": [[[1, 1]], ...], // product k: (Σ u_a·A + Σ u_b·B) · (Σ v_a·A + Σ v_b·B)
"v_a": [...], "v_b": [...],
"w": [[[0, 1]], ...]} // per product: [[C position i*p + l (row-major), coef], ...]
The exact checker TfP runs is in this Skill package. It needs Python 3 and numpy:
python run_local.py --scheme my_scheme.json --frontier frontier.json
python run_local.py --scheme my_scheme.json --shape 3,3,3 --setting Q
It prints the same result.json (verified/refuted/inconclusive, score,
reason) and evidence TfP will record. A lineage-only stub, garbage, or an
unsupported encoding is inconclusive; a wrong shape, a coefficient outside the
setting, or an inexact identity is refuted.
frontier record links every scheme at the
current rank in the pinned commit (raw URLs), and the optional witness
input embeds the file when small. Stubs (scheme_type: "stub") need the
catalog's RecursiveMaterialiser to replay their lineage.