About the Sagebrush Atlas

An agent-first companion to the LMFDB: a cache of certified computations, with LMFDB's labels, served as static files and pages that are also JSON, and able to compute what it does not store.

What is stored

For each newspace $S_k^{\mathrm{new}}(\Gamma_0(N))$ (weight 2 with $N \le 1000$; weights 4–12 with $Nk^2 \le 4000$): the dimensions of the new, old, cuspidal and Eisenstein subspaces; a Hecke operator $T = \sum c_q T_q$ whose characteristic polynomial is squarefree on the newspace; and for every Galois orbit of newforms its LMFDB label, dimension, the characteristic polynomial of $T$ (irreducible, defining the coefficient field) and the traces $\operatorname{tr} a_n$ for $n \le 1000$. Atkin–Lehner signs, the sign of the functional equation and CM are derived from these on each page. Rational newforms of weight 2 are linked to John Cremona's elliptic curves, matched by $a_p$ for $p < 1000$ computed with Sagebrush's point-counting engine.

How it is computed, and how sure it is

Sagebrush's modular symbols engine (Rust) computes each newspace exactly. The dimensions are certified against the dimension formulas, the characteristic polynomial of $T$ over $\mathbb{Z}$ is reconstructed by the Chinese remainder theorem past a rigorous bound on its coefficients, and it is factored over $\mathbb{Z}$ (Zassenhaus, checked against FLINT). The engine reports this as status proven, with the checks it made, on every page. Independently, all 5,951 weight-2 orbits agree with the LMFDB in label, dimension and $\operatorname{tr} a_p$ for all $p < 1000$.

The same engine runs in your browser as WebAssembly: Recompute in your browser on any page reruns the computation and compares it with the stored data, and spaces that are not stored are computed on the spot.

Data

Built 2026-10-10 from Sagebrush commit 155da0bc98 (the packaging revision: the producing revision was not recorded), with

cargo run --release -p sagebrush-web --example atlas -- 1-1000:2,1-250:4,1-111:6,1-62:8,1-40:10,1-27:12 1000 16
node scripts/build-atlas.mjs spaces.jsonl

(about 9 CPU-minutes). The format is described in llms.txt. The design: an LMFDB for agents.

How long will it take?

Before computing a space, the engine predicts the time and memory it will need (estimate_newforms), from quantities it knows in advance: the levels $M \mid N$ and their dimensions, the number of primes the Chinese remainder theorem will need for the characteristic polynomial and for the traces (from the same rigorous bounds the computation uses), and the number of Heilbronn matrices behind $T_p$ for $p \le B$. Each stage of the computation contributes a term, with a constant fitted to measurements of the WebAssembly engine: every stored space, and 94 more (levels up to 5077, weights up to 36, bounds 100 to 3000). Another 34 spaces of that kind were kept out of the fit to check it.

Stored spaces: 1461 spaces: 69% within a factor 1.5, 93% within 2. Larger spaces and other bounds: 81 spaces: 54% within a factor 1.5, 79% within 2. Kept out of the fit: 34 spaces: 68% within a factor 1.5, 85% within 2. The hard part to predict is the search for the Hecke operator $T$: at highly composite levels many old forms make the first choices fail, and each try costs a pass over every level. Memory is small: no stored space needs more than a few megabytes.

Each dot is a space (hover for its label): ● stored, ● larger or other bounds, ● kept out of the fit; the dashed lines are a factor 2. Computing $a_p$ for all $p < X$ (Sato–Tate) is simpler and does not depend on the curve: $0.008 + 3.2 \cdot 10^{-8}\, X \log X$ seconds (0.44 s for $X = 10^6$, 5.3 s for $10^7$, within 3% from $X = 10^5$ up) and about 12 bytes of memory per unit of $X$.