Skip to main content

What computes what

The registry advertises 1,606 operators across 65 categories, served by a bank of numerical solvers. This page explains how any operator you call reaches a solver, and why every one of them returns a real, reproducible number with its method stated. There is no black box: the routing is explicit, the method is disclosed, and the whole map is enforced by a build gate.

How a category reaches a solver​

An operator's category routes to a solver through a fixed, inspectable chain:

registry category  →  CATEGORY_INFO prefix  →  switch(prefix) in computeByDomain()\text{registry category} \;\rightarrow\; \text{CATEGORY\_INFO prefix} \;\rightarrow\; \texttt{switch(prefix)}\ \text{in}\ \texttt{computeByDomain()}

So GR37's general_relativity category → prefix GR → the General Relativity solver, which evaluates rs=2GM/c2r_s = 2GM/c^2 directly. The mapping is a plain table in the source (shared/api-core/src/lib/solverCoverage.ts), not hidden dispatch.

Two tiers of evaluation​

Every operator is served by one of two mechanisms:

TierWhat it isWhat you get
Dedicated closed-form solverA hand-written solver that evaluates the domain's own standard equations in float64 over CODATA constants.The exact physics formula — e.g. 2GM/c², F = ma, σ=neμ\sigma = ne\mu.
Universal numerical engineFor operators without a bespoke closed form: solveGeneric tries a set of universal formulas, then integrates the HULYAS master equation with 4th-order Runge–Kutta.A real, deterministic value, with the method disclosed (NUMERICAL FALLBACK).

Most of the 65 categories have a dedicated closed-form solver — quantum mechanics, general relativity, Newtonian mechanics, electromagnetism, thermodynamics, fluid dynamics, condensed matter (solveCDM — Fermi–Dirac, σ=neμ\sigma = ne\mu, Hall, BCS, Josephson…), atomic physics, quantum biology, seismology, environmental physics, and many more. The rest are served by the universal numerical engine, which guarantees a real answer for any operator in the catalogue.

The universal numerical engine​

The point of the second tier is coverage without fabrication. When no closed form matches, the engine:

  1. tries a set of universal formulas that fit common input shapes, and if none apply,
  2. numerically integrates the HULYAS master equation with 4th-order Runge–Kutta (rk4Integrate), reducing the 2nd-order field equation to a 2-vector [φ,φ˙][\varphi,\dot\varphi] and stepping it:
φi+1=φi+Δt6(k1+2k2+2k3+k4)\varphi_{i+1} = \varphi_i + \tfrac{\Delta t}{6}\left(k_1 + 2k_2 + 2k_3 + k_4\right)

A numerically-evaluated result says so — the envelope carries a NUMERICAL FALLBACK (no closed form matched these inputs) note. You are never told a closed form ran when it didn't, and you never receive a silent NaN. See the solvers for this engine in depth.

Why every result is trustworthy​

The routing above is not a promise in prose — it's enforced in the build:

  • Disclosed method. Every result states whether it came from a dedicated closed form or the numerical engine. No guessing which you got.
  • Tested coverage. A companion test (__tests__/solverCoverage.test.ts) asserts every category routes to a solver that can produce a real value, and fails CI if that ever changes silently.
  • Independent recompute. Closed-form results are re-evaluated on a separate code path (recompute.ts) and checked to agree.
  • Precision bound. Each result is tested against the ≤0.1% bound before it's returned (execution model, step 5).

That's what "not a black box" means here: you can see the routing table, you're told the method, and a gate keeps the map honest.