loopty 0.2.0__tar.gz → 0.3.0__tar.gz

{loopty-0.2.0 → loopty-0.3.0}/CHANGELOG.md

@@ -6,6 +6,1013 @@ All notable changes to loopty are recorded here. The format follows
 
 ## [Unreleased]
 
+## [0.3.0] - 2026-10-15
+
+The third release, on lanky 0.3.0. Five demos, each written after a kernel
+of sumpy, pytential, grudge or firedrake: sumpy's L2P (`examples/l2p.py`),
+grudge's weak gradient and divergence on hexahedra (`examples/hexahedra.py`)
+and its advection right-hand side (`examples/advection.py`), pytential's
+direct QBX (`examples/layer_potential.py`) and PyOP2's mass assembly
+(`examples/assembly.py`). Each states its facts, cites the theorems it
+computes, and agrees with the upstream code it mirrors (`@upstream`). isl
+decides each fact, and Lean proves it again from loopty's own description of
+the kernel, with the hints isl found. New in the language and the schedule:
+theorems a kernel cites (`uses=`), a program's postcondition, constant
+tables, `loopty.math`, kernels called inside a loop, a program's arrays over
+a domain, updates and `Schedule.atomic`, window contraction, checked layout
+maps at every size, fusion on chosen outer loops and `Schedule.assume`. The
+demos write their theorems with lanky 0.3.0's families of several indices
+and complex parts, so loopty requires it.
+
+### Added
+
+- **What fusing and contracting S1's passes buys on a CPU**,
+  `benchmarks/hexahedra.py c`: the weak gradient's three programs of
+  `examples/hexahedra.py`, the passes one after another, `fused`, and
+  `contracted`, on the C target, each checked against numpy and then timed
+  in turn on one thread. Every program is built with loopty's flags and the
+  same `--cflags`, which the CSV records, and `report` tables the rows as it
+  does the device's.
+- **sumpy's GPU schedule in the flagship's ledger** (`examples/l2p.py`):
+  `on_a_gpu = fused.retarget("opencl").tag(i="g.0")`, `E2PFromSingleBox`'s
+  own, each box a work group, written with the file's names. Its tag's two
+  facts are rows of `lanky check` (the fusions' are `fused`'s), the python
+  run lists them, and `loopty run` runs it on a device where pyopencl is
+  installed and compares it with the native run; on a GPU and on a CPU
+  through PoCL the two agreed exactly, up to 4,096 boxes. The same with each
+  box's windows, `on_a_device()`, is checked by isl in the python run; Lean
+  does not state a cast on windows each work item keeps of its own yet
+  (#295).
+- **A schedule for a device, checked where pyopencl is not installed**
+  (`loopty.lower.CheckedOpenCLTarget`). A schedule for `"opencl"` is built
+  on loopy's plain OpenCL target there, which has the same kernel and
+  imports nothing, so a file keeps its device schedules at module level and
+  `python`, `lanky check` and `loopty run` read them on any machine.
+  Generating or running their code is refused with the reason
+  (`ImportError: generating and running OpenCL code needs pyopencl, ...`),
+  and `loopty run` says `not run here: running on a device needs pyopencl,
+  which is not installed; its facts are checked all the same`, which is no
+  failure. `--target opencl` without pyopencl is refused by name, as before.
+- **A window of an array over a domain, of several writers and of a
+  recurrence** (`Schedule.contract`, #244, #213). A placement over an array
+  over a domain takes the domain's binders, and the window is the box its
+  slots span: sumpy's L2P, fused box by box, keeps one box's triangle,
+  `contract("R")` finds `lambda i, a, b: (a, b)`, 121 cells for the 66 of a
+  triangle of order 10, as plain loopy's temporary of the box. The array may
+  be stored by several statements, and read by one of them: the copy of
+  the stored rows and the recurrence `R[i, a, b] = -R[i, a - 2, b + 2]`. The
+  `definedness` fact asks that every read is of a cell one of them stored
+  before it, and the `no-clobber` fact is asked of every pair of them,
+  decided by isl and proved by Lean; a window too small, one row of the
+  triangle, is refused with the read the recurrence makes, the cell and the
+  instance that overwrote its slot. A window of a number of cells is each
+  work item's own, as loopy keeps a private temporary, so two of its
+  accesses on two work items need no order, and a read on a work item its
+  cell's store is not on is refused with the pair; the boxes on `g.0`,
+  sumpy's own schedule, each keep their triangle. A window of a size,
+  `f_window[n]`, is still one for every work item. A recurrence along a
+  loop, `f[j] = f[j - 1] + u[j]`, is a shift register too
+  (`registers=True`, the default on OpenCL): its store is the newest
+  register and its read the one before. `examples/l2p.py` now
+  runs `contracted`, its fused program with the triangle and the table kept
+  one box at a time, refuses the row with its read, and checks sumpy's
+  schedule on a device; `benchmarks/l2p.py --variant windowed` (and
+  `unrolled_windowed`) times it.
+- **A layout at every size** (`loopty.layout`, #263). A layout's body may
+  compute with a size its annotations name, so grudge's DOFArray is one
+  layout for every order, `n**3 * e + (i + n * j + n**2 * k)` over
+  `Fin[ne] x Fin[n]**3`, and so is loopy's `dim_tags` `N3,N0,N1,N2` of it,
+  each stride the product of the extents nested inside it. isl cannot state
+  `n * j`, so it decides each fact at `n` from 1 to 6 and the fact reads
+  `tested`, saying why; Lean proves it for every `n`, given the steps
+  `omega` lacks (lanky's products, quotients and multiplying out): the
+  products that bound each digit's term, a case split on the first digit
+  two cells differ in, and an address's digits by division as the cell it
+  stores. Two layouts the same is a polynomial identity Lean multiplies
+  out. All in core Lean. A refuted one names the size isl found it at,
+  `padded stores (i=0, j=1) and (i=0, j=0) both at 0 (at m=2, n=1)`. A call
+  gives the size by name, `dof_array(e, i, j, k, n=4)`.
+  `examples/hexahedra.py` declares its three layouts at a symbolic order, so
+  its claim that the DOFArray, #418's `dim_tags` and the kernels' row-major
+  arrays are one layout holds for every order, where it held at order 3 and
+  `as_dim_tags` read `x = x` in Lean.
+- **A device cast proved whole** (#188). A cast that puts a loop on a
+  hardware axis claims besides its order that no dependence joins two work
+  items, which was stated for isl only, so the cast stayed `decided` where
+  Lean is installed. Lean is now asked it too: for each dependence class,
+  that the two instances run on one work item of every axis, each one's loop
+  counted from where loopy starts it, and for a statement's sum that reads
+  what its own instruction writes, that the two never touch one cell where
+  they run apart. S1's three device launches, sumpy's tile in S2, Kulkarni's
+  split in S3 and the advection right-hand side's launches of every split
+  read `proved` by Lean, and the four demo drivers offer their casts to Lean
+  where it is installed (`python examples/hexahedra.py`: `along_s: tag(...):
+  2 facts, all proved by lean`).
+- **A program's postcondition** (`loopty.unfolding`,
+  `loopty.dataflow.program_stores`). A `@program`'s return annotation is a
+  claim about what it leaves in its parameters, written in their names and
+  the sizes its kernels name, and it is a row of the ledger, keyed as a
+  kernel's is:
+  - `tested` on the program's native runs, an equation that reads an output
+    compared at that output's class, `approx` for reals, as the compiled run
+    is compared with the native one: the calls sum in an order of their own,
+    and agree with the claim as reals and as floats to rounding. A run that
+    leaves it false refutes it, naming the cell and the two values;
+  - `decided` by isl where what the calls store decides it, as a kernel's
+    postcondition is: each call that stores no cell of an array twice, and
+    reads none before its store, has a `single-assignment` fact of the
+    program's, and each of its statements is an equation about what the
+    program leaves, until a later call writes an array it names;
+  - otherwise stated for Lean, a part of Mathlib's for a claim about reals:
+    what the calls store unfolded into the claim a pass at a time, each
+    theorem the program cites (`@program(uses=[...])`) rewritten where one of
+    its sides is, its families at the sections of the arrays they stand
+    for, `Fr (3 * x + 0)` and `w (3 * x + 0) e`, then the sums over a literal
+    range written out and `ring`. Python finds the steps, and Lean checks
+    them; a wrong one is no proof. Proved, the fact rests on the
+    `single-assignment` facts and the theorems it used.
+  In `examples/hexahedra.py`, `weak_grad` and `weak_div` claim that `grad`
+  and `div` are the dense Kronecker operators of the three directions
+  applied to the field times its metric terms, citing `sum_factorization`,
+  and with Mathlib both rows read `proved lean`: the theorem proved for
+  every order now says something about the programs that compute it.
+  A claim that names anything but the program's parameters and sizes is
+  `assumed`, and says what it names.
+- **A theorem tied to the terms a kernel adds** (`loopty.summands`, #252). A
+  cited theorem that concludes `all(c(n) == E for n in Nat if ...)` gives a
+  `by-theorem` row where a sum in the kernel's term adds `E` at whole
+  numbers `n`, with the theorem's variables bound to the kernel's
+  expressions of the sorts it takes them at (a theorem about reals says
+  nothing of complex numbers), and an identity the kernel cites, `L == R`,
+  rewrites `R` in `E` into the kernel's `L` first; the row names the
+  identity's premises that are not the theorem's. `examples/layer_potential.py`'s `single_layer` cites
+  `line_taylor` and the new `by_the_conjugate`, `ratio(alpha, beta) == -beta
+  / alpha`, the kernels' ratio by the conjugate, and its ledger reads
+  `single_layer adds line_taylor's c(n) for n in 1..5, for every c with away,
+  first and ode, read over the complex numbers`: `decided` by `theorem`,
+  resting on both theorems, and proved by Lean with Mathlib, the identity
+  rewritten and the theorem applied a term at a time. A theorem's annotation
+  that calls `loopty.math`'s `conj`, `real`, `exp` and the rest, itself or
+  through a helper the kernel calls too, reads them as lanky's functions
+  (needs lanky with `real`, `imag` and `conj`), and a kernel's postcondition
+  keeps the calls its trace makes (`loopty.math.as_traced`, `as_stated`).
+- **A postcondition's equations of reals at their class** (`loopty.reals`,
+  #254). An equation that rounds is compared after each native run within
+  the tolerance of the class of what it reads, as the compiled run is with
+  the native one, `|a - b| <= 1e-6 (|b| + 1)` for `approx`, and the
+  statement says so (`..., to the approx tolerance`); one that rounds
+  nothing, one of integers and one of an `exact` class are compared bit for
+  bit as before. Where its cells are stored once, by statements whose sums
+  run over concrete bounds, Lean proves it with Mathlib over the reals from
+  what they store, the tables at the values they hold, resting on the
+  `single-assignment` facts and on the `trace-faithful` fact.
+  `examples/assembly.py`'s `mass_ffc` now promises the element's mass,
+  `|J| (1 + delta_jk) / 24`, in place of a symmetric matrix: `tested` on its
+  runs, `proved` with Mathlib, and restated of every cell after its call.
+- **`@upstream(kernel, within=1e-12)`** (#268): the agreement with the code a
+  kernel mirrors, compared within the stated fraction of the largest value
+  of each output computed in floating point, and the row says so (`... in
+  out within 1e-12 of the largest value, on its example inputs`); an `exact`
+  output is still compared bit for bit. `examples/layer_potential.py`'s two
+  rows state it, where the bound was in a test only.
+- **Claims settled by running them** (`loopty.tested`): `@tested` on a
+  function that takes nothing and returns whether its claim held, alone or
+  with what it measured, puts the claim in the ledger as a `tested` row,
+  decided by `run`, the docstring's first line its statement; `refuted` with
+  the reason when it returns false, raises, or returns something that is not
+  a verdict. A run is evidence about its inputs, so nothing here reads more
+  than `tested`. `examples/layer_potential.py` measures pytential's Green
+  identity and the two jump relations this way.
+- **S2 of the demonstration** (`examples/layer_potential.py`): pytential's
+  QBX on its own curve. The line-Taylor theorem, for every order, in the same
+  file as the kernels that add its closed form, `coefficient(ratio, k)`;
+  pytential's single and double layer on the five-armed starfish over complex
+  points; sumpy's CPU tile (`sumpy_tile()`), its casts decided, with the
+  write sumpy silences (`write_race(write_lpot*)`) the fact `distinct
+  instances of S0 write distinct cells of out`, proved by Lean where it is
+  installed; each kernel's agreement with what sumpy's own `LayerPotential`
+  returned on the example's inputs (recorded at sumpy's commit,
+  `layer_potential_sumpy.json`), an `upstream` row; and, as tested rows,
+  pytential's identity test case and the jump relations, the errors falling
+  faster than the QBX order less 1.6.
+  `benchmarks/qbx_layer_potential.py` times the kernel against plain loopy
+  and sumpy's own on one OpenCL device, records sumpy's results, and runs
+  the kernels on the arguments pytential itself hands sumpy.
+- **S1 of the demonstration** (`examples/hexahedra.py`, #253): grudge
+  #418's sum-factorized weak gradient and weak divergence on hexahedra, the
+  kernels written for `n` nodes per axis, so that their facts hold at every
+  order. The metric product (`metric`, or `contravariant`, which sums the
+  metric terms first, three operator applications where grudge makes
+  nine), a pass per reference axis (`along_r`, `along_s`) and the last pass
+  with the three directions summed (`gradient_along_t`,
+  `divergence_along_t`), chained by the programs `weak_grad` and
+  `weak_div`. The Kronecker theorem the passes rest on,
+  `sum_factorization`, for every `n`, proved by Lean with Mathlib and tested
+  without it; the DOFArray's layout, at order 3, the same as #418's
+  `dim_tags` `N3,N0,N1,N2` and as the kernels' row-major arrays, each a
+  fact. The passes fused as deep as each pair allows, one loop deeper
+  refused with its pair and the fusion of fewer loops named, and what
+  passes between them kept a row (`w`) and a slab (`v`) at a time; on a
+  device, three launches, every node on a work item
+  (`passes_on_a_device`). `benchmarks/hexahedra.py` times the variants
+  against the same kernels in plain loopy and against grudge on one device,
+  and compares them with #418's own `weak_local_grad` and `weak_local_div`
+  (`agree`): on a warped mesh at orders 3 to 6 they agree to `3e-15` to
+  `5e-15`, natively, compiled, fused and contracted, and as the device
+  launches.
+- **The demo's flagship, `examples/l2p.py`**: sumpy's L2P for the 2-D
+  Laplace kernel (`E2PFromSingleBox` with the compressed Taylor expansion),
+  in one file and one ledger. The claim sumpy's reconstruction rests on,
+  for every order (lanky#86), and its form box by box on the triangle `a + b
+  <= p`, both proved by Lean with Mathlib; sumpy's storage index as a
+  checked layout; `unpack`, whose postcondition, decided from what it
+  stores, is sumpy's storage order, `reconstruct`, whose postcondition is
+  decided from what it stores and is the theorem's hypotheses, so the
+  theorem applies, and `evaluate`, composed by the program `l2p` and fused
+  box by box; the interchange of the triangle's loops refused with isl's
+  pair, and each box's triangle kept in a window (above). The program agrees with sumpy's own kernel on the file's inputs to
+  round-off (`upstream`, below), and with the charges' potential to `4e-13`
+  at order 10.
+- **Agreement with the code a kernel mirrors**, `@upstream(kernel)`
+  (`loopty.upstream`). The decorated function computes, on the file's
+  example inputs, what the code the kernel is written after computes there;
+  `lanky check` runs the kernel natively on the same inputs and compares,
+  output by output, at the accuracy the kernel's types claim, a dense
+  output in its own shape. The row is `tested` by `upstream`, `refuted`
+  with the cell and both values (or both shapes), or `assumed` with why
+  where the function cannot run: its package is not installed, or its
+  recording is not there.
+- **`loopty.math.ipow(x, n)`**, `x` to an integer power multiplied out as
+  loopy multiplies one, by squaring, rounded at every product, in both runs:
+  natively by the same loop (`loopty.math.integer_power`), compiled as
+  loopy's `loopy_pow_<base>_<exponent>`. The two runs agree bit for bit, in
+  single precision too. An integer base or a real power is refused, natively
+  from the values and traced from the operands' types, and so is the
+  smallest power of the type the compiled kernel holds the power in
+  (`-2**31`, `-2**63`), whose negation loopy's helper cannot take. `x ** n` of a real `x` stays numpy's power, the C
+  library's `pow` in both runs; at the flagship's Taylor sum `ipow` is an
+  order of magnitude faster on the C target (`benchmarks/l2p.py`).
+- **`benchmarks/l2p.py`**, which times sumpy's own `E2PFromSingleBox`, the
+  same algorithm written directly in plain loopy (loopy #970's L2P
+  microkernel with the Laplace step put back, and variants that make
+  loopty's choices), and loopty's schedules of `examples/l2p.py`, on one
+  tree and one device, and compares their potentials with each other and
+  with the direct sum. On the C target plain loopy is built with the flags
+  loopty builds its kernels with (`-fwrapv`; `--no-wrapv` for loopy's
+  alone), and each record names the flags it was built with. It also
+  records sumpy's potential on the example's inputs, for the `upstream`
+  row.
+- **The S3 demo: firedrake's PyOP2 assembly loop** (`examples/assembly.py`).
+  FFC's P1 mass kernel of firedrake's PyOP2 tests, `mass_ffc`, with its
+  15-digit tables as constant tables, is a kernel of its own, called inside
+  the loop over the cells as PyOP2 calls it, `mass_ffc(coords[cell[c]],
+  Ae[c])`, and the cell's matrix applied to `u` is added into the nodes,
+  `y[cell[c, a]] += ...`. The three identities the loop rests on are lanky
+  theorems in the same file, proved where Mathlib is installed: the 3-point
+  rule integrates every quadratic exactly, a cell's mass matrix is `|J| (1 +
+  delta_jk) / 24`, and the scatter keeps the total on every mesh. PyOP2's GPU
+  split is refused with the node its two test triangles share and accepted
+  once the updates are atomic, and both PyOP2 branches' schedules take the
+  assumptions their transforms make (`assume("nc >= 1")`, `assume("nc % 4
+  == 0")`). `benchmarks/assembly.py` times loopty's schedules against a
+  plain-loopy transcription of PyOP2's wrapper with Kulkarni's and Sun et
+  al.'s transforms applied, and with `--nested` against the transcription
+  given loopty's nesting of a cell's loops under the cell loop, which is
+  what decides where loopy puts the `ilp` loop of Sun et al.'s split
+  (interleaving the four cells, or running each whole); and
+  `benchmarks/assembly_agreement.py` compares
+  the example with firedrake's own assembly and PyOP2's own `par_loop`.
+
+- **The advection right-hand side on hexahedra** (`examples/advection.py`),
+  the stretch of the S1 demo: grudge #418's `WeakAdvectionOperator` with the
+  upwind flux, from grudge's own geometry, as kernels for every order. The
+  flux reads the neighbor's value through the face maps, in bounds by type;
+  the inverse mass is pushed inward, as grudge #362 rewrites it, and the
+  same kernels take the GLL quadrature's tables. Three lanky theorems, proved
+  where Mathlib is installed: the two rearrangements, and that the lift onto
+  the face nodes is the transpose of the face gather, so it keeps the
+  element's total. The kernels fuse on the element, one loop deeper is
+  refused with its pair, and the fluxes are kept an element at a time;
+  libParanumal's lift onto the face nodes without its barriers is refused
+  with the edge node two faces update, and accepted atomic. Five splits on a
+  device (libParanumal's volume and surface, the fluxes first, three
+  launches, one, one from the metric terms), each launch a checked schedule;
+  `benchmarks/advection.py` times them in five shapes beside the same
+  launches in plain loopy and grudge's own right-hand side, and compares
+  them with grudge's on a warped periodic mesh.
+
+- **A kernel's postcondition decided from what its statements store**
+  (`loopty.dataflow`, #113). Where no cell of an array a kernel writes is
+  stored twice, or read before its store, a `single-assignment` fact says
+  so, decided by isl, and what each statement stores is what the kernel
+  leaves: its value equation, `off[r + 1] == off[r] + cnt[r]` at every `r`
+  of `S1`'s loop. isl decides the postcondition under the equations, each
+  taken at the cells the claim reads, so `scan`'s reads `decided isl`,
+  resting on the `single-assignment` fact of `off`, and with Lean `proved
+  lean`, where it read `tested native`. An equation of reals isl cannot read
+  is an atom, one per equation as written, its cells canonical and its sides
+  in either order (`discharge(..., atoms=True)`), so `R[a + 2, b] == -R[a, b
+  + 2]` is decided as what the recurrence stores at `(a + 2, b)`; Lean
+  states it with Mathlib's reals and proves it by `linarith`. The native
+  runs still test the postcondition (`native` in its provenance), and one
+  that refutes it refutes it; one the equations do not decide keeps the
+  runs' status, with why (`undecided`): a cell stored twice, a read before
+  its store (the instance that stores a cell and reads it, however its
+  index is spelled, `x[i] = 2 * x[i + 1 - 1] - 5`, reads it first), a write
+  under a guard isl cannot state, an update (`y[i] += v`, or a scatter-add
+  through a map, `y[cell[c, k]] += v`), whose cells hold what they held on
+  entry plus every update: `S0 updates y[cell[c, k]] in place, so a cell of
+  y holds what it held on entry plus every update, not what one statement
+  stores`.
+- **Theorems a kernel cites**, `@kernel(uses=[on_the_triangle])`. A theorem
+  whose hypotheses are conjuncts of the postcondition, up to the names of
+  their binders, with a family `R(a)(b)` matching the cell `R[a, b]`, gives
+  its conclusion at the kernel's arrays: a `by-theorem` fact, `decided` by
+  `theorem` and resting on the theorem and the postcondition, whose
+  unbound variables stay universal and whose unmatched hypotheses are its
+  own, named in the row. For `examples/taylor_reconstruction.py` it reads
+  `by on_the_triangle, for every D with pde and stored: ... R[a, b] ==
+  D(a)(b)`. Lean checks the application, the theorem as it was proved
+  applied with the arrays loopty matched, so a wrong match is no proof. A
+  theorem whose conclusion is a conjunct of the postcondition decides that
+  conjunct instead. A match is made only where it says something of what
+  the kernel computes: every hypothesis about an array the kernel writes is
+  a conjunct of the postcondition (a kernel whose recurrence is off by one
+  gets nothing), and a conjunct about reals is matched only where nothing
+  in it rounds, copies and sign changes, since the theorem reads it as
+  reals. A family into `Nat` or a `Fin` sort stands for an array the kernel
+  does not write; the cells it writes take a theorem over `Int`. The
+  theorem's variables are put in wherever they are, every sort included: a
+  `D: Fn[Fin[n], Real]` nothing binds, with `n` matched to the kernel's `p`,
+  ranges over `Fin[p]` (#239), and `m` in `m**2` is the `m` the match bound,
+  never a kernel name of the same spelling. A family is applied as `R(a)(b)`,
+  `R(a, b)` or `R[a, b]`, as lanky reads them.
+
+  ```python
+  @kernel(uses=[on_the_triangle])
+  def reconstruct(
+      c: Arr[Where[a : Fin[2], b : Fin[p + 1], a + b <= p], Real],
+      R: Arr[Where[a : Fin[p + 1], b : Fin[p + 1], a + b <= p], Real],
+  ) -> copies & recurrence:  # the two conjuncts, written out in the example
+      ...
+  ```
+
+  ```console
+  $ lanky check examples/taylor_reconstruction.py
+  ...
+  decided under on_the_triangle  assumed    theorem      taylor_reconstruction.py:116  reconstruct      by on_the_triangle, for every D with pde and stored: forall a in Fin(...
+  ...
+  ```
+- **`lanky check` lists a file's schedules** (#191). The casts of every
+  schedule a file holds at module level are rows of its ledger, under the
+  kernel or program they schedule, decided by isl as each step was taken
+  and proved by Lean where it is installed; two schedules that share their
+  first steps share those facts, which are listed once.
+- `examples/taylor_reconstruction.py`: sumpy's compressed Taylor
+  reconstruction from the theorem to the kernel to the schedule, in one
+  file and one ledger, the seed of the demo's flagship.
+- A matched theorem's family of families applied one index at a time,
+  `R(a)(b)`, stands for an array indexed at once, `R[a, b]`, for a program's
+  cited theorems too.
+- **Window contraction** (`Schedule.contract`,
+  [#132](https://github.com/xywei/loopty/issues/132)): an array a program
+  makes, kept in the cells live at once. Fused one step behind, the Burgers
+  divergence reads `f[j]` and `f[j - 2]` at step `j`, so
+
+  ```python
+  fused = Schedule(burgers_rhs).fuse("flux", "divergence", shift=1)
+  fused.contract("f")                  # lambda j: j % 3, double f_window[3]
+  ```
+
+  keeps three cells and computes each flux once, where `substitute("f")`
+  computes it twice. A placement is a Python function from a cell's indices
+  to its slot, quasi-affine, given (`contract("f", lambda j: j % 3)`) or
+  found, axis by axis, outermost first, along the order as it stands (one
+  row of the sum-factorized passes' `v`, `lambda e, a, b: b`). The step is
+  legal when every read is of a cell the producer stored before it (the
+  strict `definedness` fact a substitution asks) and no read sees its slot
+  overwritten (a new `no-clobber` fact, decided by isl over the schedule's
+  order, refuted with the read, the cell it reads and the instance that
+  overwrote its slot, `contract('f', lambda j: j % 2) illegal: instance
+  divergence.S0[i=14] reads f[13], which flux.S0[j=13] stored in slot 1,
+  after flux.S0[j=15] stored f[15] there`). From then on every pair of
+  accesses to one slot is a dependence of the schedule, in the order they
+  ran, so a later step that breaks the window, or puts its slots on two work
+  items, is refused with its pair. Two lowerings: modulo addressing,
+  `f_window[j % 3]`, and a shift register (`registers=True`, the default on
+  OpenCL) whose every access has a constant index, the window shifted down
+  by one at each step of its loop, which a device keeps in registers. The
+  zeros the program made the array with are dropped, as a substitution
+  drops them. Lean states `no-clobber` from loopty's description: three
+  instances through every step's map, the placement with `%` by a number,
+  and the time vectors of the order. `examples/fusion.py` and
+  `examples/sum_factorization.py` show it; an array its producer reads, or
+  that two statements store, and a window per work item are not done (#213,
+  #214). A refused window names the fix, `contract('f') finds the smallest
+  window that keeps every read, lambda j: j % 3`, and a step that breaks one
+  the instance that would now overwrite a slot first. A window and a
+  substitution of an array computed from it are refused together, in either
+  order (#229): the substitution moves the window's reads. Every window of the
+  tests computes the bits the array stored in full does, on C and on an
+  OpenCL device, and a shift register inside an outer loop shifts in each of
+  its steps.
+- **Checked layout maps** (`loopty.layout`): a layout is a Python function
+  from a cell's indices to its address, whose annotations say which cells
+  (one `Fin` per axis, or one parameter over a `Where`) and which buffer
+  (the return annotation), and `layout(first, second)` is a layout of
+  pieces:
+
+  ```python
+  @layout
+  def dof_array(e: Fin[ne], a: Fin[N], b: Fin[N], c: Fin[N]) -> Fin[ne * N**3]:
+      return N**3 * e + (a + N * b + N**2 * c)
+
+  as_dim_tags = dof_array.same_as("N3,N0,N1,N2")   # loopy's dim_tags
+  ```
+
+  `lanky check` asks three facts of each layout, every cell at an address of
+  its buffer, no two cells at one address, and a cell at every address, and
+  one of a `same_as` claim, every cell stored where the other layout, or
+  loopy's `dim_tags`, stores it; isl decides each and Lean proves it, the
+  third with isl's inverse of the layout, in pieces with `//` and `%`, as
+  its witness. A layout of one piece is called as its function, so a kernel
+  reads through it; a call whose address is not the one the facts are about
+  (a constant or a helper the function computes with changed since it was
+  declared) is refused, with both addresses.
+  `examples/storage_layouts.py` checks sumpy's
+  compressed-Taylor storage index in two pieces, and grudge #418's
+  `N3,N0,N1,N2` against modepy's F-order reshape of the DOFArray; the
+  reshape in C order, `N3,N2,N1,N0`, is refuted with a cell, in words:
+  `dof_array stores (e=0, a=1, b=0, c=2) at 19, and dim_tags N3,N2,N1,N0 at
+  11`; so are two cells at one address and an address with none. A buffer of
+  several axes, and an argument that names its layout, are not done (#216).
+- **A kernel called inside another kernel's loop** (`loopty.calls`). A
+  kernel body calls a kernel as Python calls a function. A kernel whose
+  return annotation is a sort is a rule: it returns its value and writes
+  none of its parameters, and a call of it is that value; a kernel that
+  writes its parameters is called as a statement and writes through what it
+  is given:
+
+  ```python
+  @kernel
+  def dot(a: Arr[Fin[n], Real], b: Arr[Fin[n], Real]) -> Real:
+      return reduce_sum(a[k] * b[k] for k in a.dom)
+
+  @kernel
+  def matvec(A: Arr[Fin[m], Fin[n], Real], x: Arr[Fin[n], Real],
+             y: Arr[Fin[m], Real]):
+      for i in y.dom:
+          y[i] = dot(A[i], x)
+  ```
+
+  `A[i]` is the row of `A` and `x[col[r]]` the cells of `x` a row of
+  indices picks, as in numpy, so a sparse product is `y[r] = dot(val[r],
+  x[col[r]])`; a row of a ragged array, of a table, or a whole array over a
+  domain may be passed too. A parameter of a function sort, `f: Fn[Fin[3],
+  Real]`, takes a `lambda` or another rule, so that a quadrature rule is
+  applied to an integrand, `integrate(lambda q: PHI[q, j] * PHI[q, k])`.
+  Traced, the call is inlined: the callee's body runs again in the caller's
+  trace against views of the caller's arrays, its loops and sums nested in
+  the loops around the call, a binder named like a name of the caller's
+  given one of its own (`k_0`), which is loopy's substitution rule with a
+  domain of its own (loopy #1044) expanded where it is used, and every fact
+  of the caller is about the expansion. The shapes are unified at the call,
+  size by size, and a call whose sizes nothing says agree is refused, naming
+  the axis. What the callee's contract checks of each call natively, the
+  caller owes at every point it calls, as facts isl decides and Lean states
+  from loopty's own description of the call: each row passed in bounds
+  (`A[i], the row passed to dot as a, is in bounds wherever dot is called`),
+  the cells a gather picks in bounds by type, an integral scalar in its sort
+  (kind `argument`), two rows of one array apart where the callee writes
+  one (kind `distinct-arguments`); and after each call the callee's
+  postcondition, restated of what the call passed and resting on the
+  callee's own fact (kind `postcondition-in-scope`). An argument is
+  evaluated once, when the call is made, as in Python: every cell read for
+  the value of a scalar argument, or for the indices of a row (`p[i]` of
+  `A[p[i]]`), is owed in bounds at every point of the call, whether the
+  callee uses the parameter or not, and a call whose
+  callee writes an array an argument reads (`scale(A[i], A[i, 0])`) is
+  refused, naming both; so is a function given whose default or captured
+  name holds a value read from such an array (`lambda q, saved=x[0]:
+  saved`), which natively is the value when the function was made. A
+  scalar argument is converted into the sort the callee declares, as its
+  contract converts it natively (#232): a double given for `s:
+  np.float32` is `np.float32(x[i])` in the caller's term, which the
+  interpreter computes as numpy does and the lowering writes as C's cast,
+  and a loop variable given for `Int` is a numpy `int64` beside a
+  `float32`, while an index or a comparison of it reads as the caller's
+  own, `A[i, i]`. What the contract refuses is refused where it is passed:
+  a real or a truth value for an integral sort, a number for `Bool`, a
+  complex value for a real sort (naming `real(z[i])`), a literal numpy
+  does not convert (`300` for `np.int8`), and, when the compiled run is
+  asked for, loop arithmetic a narrow integer does not hold where the call
+  is made. A callee's positional-only parameters are passed in order
+  (#233). A rule may be applied to a function that applies it again, `integrate(lambda q: integrate(lambda p: ...))`; a kernel that
+  calls itself, directly or through the functions it is passed, is
+  refused. A rule on its own is the kernel that
+  writes its value into a one-cell array, `result[0]`, which `loopty run`
+  compiles and compares with the native call; one that takes a function is
+  compiled where it is called. Natively, a call inside a `when` whose guard
+  is false is not made, and a rule's value there is `0`, so the value of a
+  rule called inside a `when` block is refused where it is used after the
+  block. `examples/calls.py` has `dot` in a matrix-vector
+  and a sparse product, and firedrake's P1 quadrature rule applied per
+  element. A callee's update, `y[cell[k]] += yl[k]`, is an update of the
+  caller, of the class of its sum and owing no distinct writes, as written
+  inline: a step that runs two at once is refused with a pair of the
+  caller's loop and the callee's read off the example inputs (`S0[c=0, k=2]
+  and S0[c=1, k=1] both update y[3]`), and `atomic('y')` on the caller
+  lifts it. An integer a callee is given for an `Int`, `np.int64(c)`,
+  keeps such an update exact. A window (`Schedule.contract`) is taken over
+  the statements of the kernels a program's kernels call, and its
+  `no-clobber` fact is about them; a callee reads through a declared
+  layout, which is checked against its facts where it is called.
+- **A program's arrays over a domain** (#74). A program's callee may take
+  an array over a `Where`, `Sigma` or union domain: the domain's sizes are
+  unified across the calls, binder by binder, and two calls given one array
+  have to agree on its points, compared as isl sets. A program may make an
+  array over a domain, like an argument over one, `Arr.zeros_like(L)`, or
+  of a declared shape, whose sizes it reads off its arrays as it does
+  natively:
+
+  ```python
+  @program
+  def pair_sums(x, e):
+      f = Arr.zeros(TRIANGLE, n=x.dom.size)
+      fill(x, f)
+      rowsum(f, e)
+  ```
+
+  It is a temporary of the lowered kernel, stored boxed and zeroed over its
+  points where the program makes it, its edges have definedness facts as a
+  dense temporary's do, and a schedule fuses through it; `Schedule.pack`
+  stores a program's argument over a domain packed. A declared dense shape
+  is `Arr.zeros((x.dom.size, 3))`, and a run whose sizes make one of its
+  lengths negative is refused compiled, as numpy refuses it natively.
+  `Schedule.contract` may keep a dense one in a window; one over a domain is
+  refused there, naming the fix, keep it whole or `substitute` it
+  ([#244](https://github.com/xywei/loopty/issues/244)).
+
+- **Constant tables** (`loopty.table`): quadrature weights, a basis
+  tabulated at the quadrature points, a differentiation matrix, declared
+  next to the kernel as the numpy array they are, `W = table([1 / 6, 1 / 6,
+  1 / 6])`, and read by the body as an array is, `W[q]`, `W.dom`. Natively a
+  table is a read-only copy of its values. Traced, it is recorded in the
+  term (`Term.tables`) under the name the body reads it by, and each read is
+  an access whose in-bounds fact isl decides over the table's shape. Lowered,
+  it is a read-only loopy temporary with the values as its initializer, which
+  loopy writes once with every digit, `static double W[3] = {
+  0.16666666666666666, ... };` on the C target and `__constant` on OpenCL, so
+  both runs read the same numbers; the interpreter reads them too. Complex,
+  single precision and integer tables are read in their own dtype. A table
+  read in a helper of the body is the kernel's, named as it is declared, a
+  program holds one table for every call that reads it, and a table named
+  like a parameter or a size of the kernel is named apart, `y_table`.
+  Writing one is a `TypeError` in both runs. Natively a table is read as an
+  array is: an index is never counted from the end, and a read out of range
+  under a false `when` answers zero. A table holds finite numbers (#193), in
+  a type the compiled kernel has (not `float16` or `longdouble`),
+  is no argument (an array of its values is,
+  `Arr.from_numpy(W.values.copy())`), and is read in a statement's values,
+  not in a loop's bound (#194); each of these is refused with the fix named.
+  A compiled run refuses a read-only array for a parameter it writes, such
+  as a table's `W.values`, which it wrote into before failing. On OpenCL a
+  complex table is an array of the kernel's own, since pyopencl writes its
+  values as calls, which a `__constant` array cannot be initialized by.
+- **`loopty.math`**: `sqrt`, `exp`, `log`, `sin`, `cos`, `real`, `imag` and
+  `conj` for kernel bodies. Each is numpy's natively and a call the
+  trace records, which the interpreter evaluates with the same numpy function
+  and the lowering writes as the target's library function, `csqrt` and
+  `creal` of a complex number on the C target and pyopencl's `cdouble_sqrt`
+  and `cdouble_real` on OpenCL, in the type numpy computes it in: `sqrt` of
+  an integer is a double (`sqrt((double) (k[i]))`), where loopy refused it on
+  the C target and took it for a `float` on OpenCL, and `real`, `imag` and
+  `conj` of a number that is not complex are the number, `0` and the number,
+  where loopy wrote `creal` of a double. A function numpy computes in half
+  precision, `sqrt` of an `int8`, is a `TraceError` naming `sqrt(1.0 *
+  k[i])`. pytential's line-Taylor single layer over complex points,
+  `real(log(c[t] - y[s]) - ...)`, runs, checks and compiles as any kernel
+  (`examples/layer_potential.py`). A postcondition may call them too, `->
+  all(y[i] == sqrt(x[i]) for i in Fin[n] if x[i] >= 0)`, and is tested after
+  each native run with numpy's, where it was left `assumed`, not evaluated.
+  `examples/p2p.py` calls `loopty.math.sqrt` where it built the call by hand.
+  A value of one compares and combines as any traced value does,
+  `when(sqrt(x[i]) > 1.5)`. numpy's own functions, Python's `math` and
+  `x[i].real` take numbers: a body that calls them on a traced value is
+  refused at its line, with the `loopty.math` function to write (#195),
+  where it failed far from the body (numpy's "loop of ufunc does not support
+  argument 0 of type Subscript", pymbolic's `UnknownVariableError`).
+- **A sum's loop ordered outside a loop of its statement**
+  (`Schedule.prioritize("s_outer", "t_inner")`). sumpy's CPU tile of
+  a layer potential splits the targets by 16 onto a group and its work
+  items, splits the sources by 256, and runs the sources' outer loop
+  outside the work items' loop; `prioritize` and `interchange` refused the
+  sum's loop as no loop of the kernel. A loop of a sum named before loops
+  of its statement now runs outside them, each sum still adding its terms
+  in its own order, so nothing is reassociated; a loop the sum runs outside
+  of orders none of the instances in it, so a dependence between two of
+  them is refused with its pair, as one across an `ilp` loop is. loopy runs
+  the order only where it keeps an accumulator per instance, on a hardware
+  axis or an `ilp` loop (`acc[16]` on the C target); on a loop that runs in
+  sequence it keeps one and drops the order, and the schedule's `buildable`
+  fact is refuted with that reason and the tag that fixes it. Two loops of
+  one sum are never reordered, and an inner one never runs outside a loop
+  its outer one does not.
+- **Fusion on chosen outer loops** (`Schedule.fuse(..., loops=1)`). A
+  fusion took every loop both sides have, so two passes over elements, the
+  second of which reads every cell of the element the first wrote (a
+  sum-factorized operator, one reference axis per pass), could not be fused
+  at all: fused on the element and the row, the second pass reads a cell of
+  the element before the first stores it. `loops` fuses only that many of
+  the outer loops and leaves the loops inside them one after the other, the
+  producer's first, checked as every fusion is. A refused fusion now names
+  each fusion it checked that is accepted: the least shift at the same
+  depth, as before, and the deepest fusion of fewer loops, `fuse('along',
+  'along@2', loops=1)`.
+
+- **isl decides, Lean checks** (`loopty.description`, `loopty.obligations`).
+  Every fact isl decides about a kernel, a program or a schedule's step is
+  also stated as lanky terms for lanky's Lean oracle, which proves it with
+  `omega`; where Lean is installed such a fact reads `proved` by `lean`, and
+  where it is not, nothing changes. The statements come from loopty's own
+  description of the kernel and never from a set isl computed: every set
+  loopty builds keeps the text it was written from, on the set itself
+  (`description_of`), with each call's renaming, and every schedule step a
+  record of its maps as written (`Schedule._records`, `loopty.schedule.Step`).
+  In bounds, distinct writes, element sorts, the source order, a cast's
+  bijectivity and its legality (one part per dependence class), and what a
+  program's call may assume (requirements and flat accesses under the
+  hypotheses isl used) are stated. isl's work is used as hints Lean checks:
+  its functional form of a step's map as the witness that the step is total,
+  its `lexmax` pieces as the witness of a definedness, the instances it took
+  of a universal hypothesis, and its counterexample to a refuted fact, which
+  Lean proves false. A refuted fact is offered to Lean only as that
+  counterexample, and one with none Lean can check (a refused bijection, say)
+  is not offered at all, so that a proof never reads `proved` where isl
+  refused. A map given to `Schedule.affine` as isl writes it (`2 t + i`,
+  `floor(i / 4)`) is read back too. Facts loopty states for isl alone (a
+  rewritten layout, the casts after a substitution, a cast with a hardware
+  axis) say so. `docs/lean-checks.md` explains it, and
+  `scripts/lean_coverage.py` reports what Lean proves of every example and
+  test kernel.
+- `loopty run` asks Lean about each fact isl decided that it reports (the
+  casts, a layout's facts), names what Lean did not prove under the table
+  (with `--verbose`, also what Lean was not asked about, and why), and prints
+  the Lean with `--show-lean [TEXT]`; `loopty check --show-lean` passes it to
+  `lanky check`.
+- **Definedness inside one kernel.** An array a kernel reads only at cells
+  an earlier instance of its own wrote, as `scan` reads `off[r]`, gets a
+  `definedness` fact where isl shows it, stated for Lean as a ∀∃ with isl's
+  last writer as the witness. A kernel that reads what an array held when it
+  was called gets none, and a write under a guard isl cannot state
+  (`with when(x[i] > 0)`) counts for nothing, since its domain is wider than
+  where it stores. A program's definedness of an edge is stated the same
+  way.
+- **Mixed subscripts.** An access whose indirect axes are indexed by a value
+  of their own sort and whose other axes are affine, `X[cell[c, k], d]`, is in
+  bounds by type on the first and decided by isl on the rest, where it was
+  `assumed`; Lean states the whole access with the type as a hypothesis.
+- **`Schedule.assume(condition)`**: a condition of the sizes, `"n % 4 == 0"`,
+  taken as given, as loopy's `assume`. loopy is told, every later cast is
+  decided and stated where it holds and rests on an `assumption` fact, and a
+  call whose sizes break it is refused before anything is compiled.
+- **Updates, a scatter-add: `y[cell[c, k]] += yl[c, k]`.** A statement
+  that adds to the cell it writes a value that reads nothing else of the
+  array is an update (`Stmt.exactness`). Its sum has the class of what it
+  adds, as a reduction's has: `approx` for `Real`, `exact` for integers. Two
+  updates of one cell give the same sum in either order, so they are no
+  dependence of each other (`loopty.flow.dependences`), and a schedule may
+  reorder them, which it records as a reassociation, as `realize` does. An
+  update whose instances can add to one cell owes the class of its sum, `the
+  accumulation into y[cell[c, k]] over c, k is approx`, instead of distinct
+  writes, which were refuted before: a correct assembly loop or row sum
+  written with `+=` now checks clean. An update of a cell of its own at
+  every instance, `y[i] += a * x[i]`, still owes distinct writes.
+- **`Schedule.atomic("y")`.** Two updates of one cell that a step runs at
+  the same time, on two work items or under `ilp` or `vec`, can lose one of
+  the two values. Such a step is refused with the pair and the fix:
+  `tag(c_outer='g.0', c_inner='l.0') illegal: S1[c=0, k=2] and S1[c=1, k=1]
+  both update y[3] on example_inputs() (nc=2, nv=4), where cell[0, 2] = 3
+  and cell[1, 1] = 3, ...; make the updates atomic, with atomic('y') before
+  this step`. After `atomic("y")` the step is accepted, it records `atomic
+  updates of y run at the same time after tag(...)`, and `y` is compared at
+  `reassoc`. On OpenCL each update is loopy's `AtomicUpdate`, a
+  compare-and-swap loop, and every other access to `y` is atomic too, as
+  loopy requires. loopy has atomic updates of `int32`, `int64`, `float32`
+  and `float64` only; any other dtype is a `buildable` fact refuted. On the
+  C target, which runs in one thread, the code is unchanged. `atomic`
+  refuses an `exact` accumulation, as `realize` refuses a tree of one
+  (#200), and an array nothing updates, naming what each statement that
+  writes it does instead. `examples/assembly.py` is PyOP2's P1 mass action:
+  its GPU split refused with the node PyOP2's two triangles share, accepted
+  with atomics, and run on the PoCL CPU device (`docs/device-runs.md`).
+  An update may read a window (`Schedule.contract`), `y[node[i]] += f[i +
+  1] - f[i - 1]`, and `atomic` does not lift the order of the window's
+  slots; a window of an array that is updated is refused, since the
+  updates add to the zeros a window drops, with the fix: `contract('f'):
+  added_flux.S0 updates f[j] in place, ...; store each cell once, f[j] =
+  ... (a reduce_sum where the updates run over a loop), or keep f whole`.
+- **Refusals name a pair from the data.** isl cannot follow a cell read
+  from an array, `y[cell[c, k]]`: it takes it to be any cell, so the pair it
+  picks need not share one. A refused cast through such a cell now names two
+  instances that touch one cell on an input, with what the subscripts read
+  there. The inputs are tried in turn: the schedule's own example inputs,
+  the module's `example_inputs()`, then drawn ones. Where none has such a
+  pair, the message says the pair is isl's, naming the subscript isl cannot
+  follow; so it does for a read a substitution moves (`substitute('f')
+  reads y where f was read, which no run of an input shows`), which no
+  input's run makes. `loopty.interpret.interpret(..., log=...)` records the
+  cells each instance touches.
+
+### Changed
+
+- **The README opens with a front page**: what loopty is to someone who
+  writes loopy kernels, the flagship `examples/l2p.py` in its three layers
+  with its refusals and six rows of its ledger with Lean and Mathlib, the
+  five demos in a table (what each is written after, what its ledger has,
+  how it compares), how to run them, and where the limits are.
+  The reference below it is as it was, the spmv walk-through under its own
+  heading and the paragraphs the front page now says shortened. Run it and
+  Install install the 0.3.0 releases from PyPI and clone the `v0.3.0` tag
+  for the examples.
+- **Requires lanky 0.3.0** (`lanky>=0.3.0`, was `>=0.2.0`). Its Lean oracle
+  proves a plugin's parts with the solver's hints, which is how loopty
+  states each fact isl decides, and its families take several indices,
+  `D[a, b]`, and complex numbers apart, which the demos' theorems are written
+  with. The tests that skipped on lanky 0.2.0 (the demos `l2p`, `hexahedra`,
+  `advection` and `layer_potential`, the benchmark driver's test, the
+  statements for Lean, rewrites by an identity) no longer skip, so CI's job
+  against the released lanky runs them. `[tool.uv.sources]` still resolves
+  lanky from `../lanky` in a checkout, and the built distributions ask for it
+  from PyPI.
+- **The interpreter finds a sum's points once, not at every instance**
+  (lanky #125). The faithful check runs each kernel's term through
+  `loopty.interpret`, and a reduction asked isl for its points at every
+  statement instance: it fixed the loop variables, the domain's parameters
+  and enumerated. Now a reduction's domain is enumerated once per run at
+  the values of its parameters, its points kept by the loop variables each
+  instance fixes, and where it is the loops' points times the sum's (a sum
+  over `Fin[n]` in a loop nest), as its two factors. Each instance reads its
+  own points, in the same order, and the work limit is checked on them by
+  their bounding box as before. The rule for a node is found once per type.
+  `lanky check examples/hexahedra.py` spends 7 s in the interpreter where it
+  spent 31, and takes 12 s of CPU where it took 38 without Lean; every
+  example's ledger, JSON included, is what it was.
+- **`loopty run` says what a row lacks to be proved**, with lanky's
+  `WITHOUT LEAN` and `WITHOUT MATHLIB` lines under its table, and sizes the
+  table's statement column to the terminal, as `lanky check` does, where the
+  lanky it runs with has them. The transcripts show each statement whole,
+  wrapped under its row.
+- A refusal names each instance of its pair by the statement as the source
+  writes it, the line it is on, and its coordinates by the names the source
+  gives its loops (#260). The flagship's interchange reads `R[i, a, b] =
+  C[i, a, b] (l2p.py:276) at i=0, a=1, b=9 writes R[0, 1, 9], read by R[i,
+  a, b] = -R[i, a - 2, b + 2] (l2p.py:278) at i=0, a=3, b=7, scheduled
+  earlier`, where it read `instance S0[i=0, a=1, b=9] writes R[0, 1, 9]
+  read by S1[i=0, a=3, b=7] scheduled earlier`; S3's race, `y[cell[c, a]]
+  += reduce_sum(...) (assembly.py:269) at c=0, a=2 and at c=1, a=1 both
+  update y[3]`. A long statement keeps what it writes into and shortens the
+  calls on its right, `reduce_sum(...)`; an instance of the statement just
+  named is `the same statement at t=1, i=7`. The same holds for every
+  refusal that names a pair (of `tile`, `interchange`, `skew`, `affine`,
+  `fuse`, `tag`, `contract`, `substitute`), and for a disjoint-writes fact
+  refuted on an input, and the fix each names is kept. A pair on two work
+  items says where each access runs by what it does, `the write is in a
+  sum, on every work item of l.0`, where it named the statement a second
+  time. A fact's `witness` keeps the ids, `S0[t=0, i=8]`, and so does a
+  term written by hand, which has no source.
+- A schedule's facts are at the line of the step that made them, the
+  `.split(...)` or the `.assume(...)` of a chain, and its run at the line
+  the schedule is finished, its last step (#259). They were all at the
+  kernel's first statement, which for S3's `mass_action`, whose first
+  statement is the one of `mass_ffc` it calls, was a line in `mass_ffc`.
+  The run of a kernel the file does not schedule is at the kernel's
+  definition.
+- A sum over a `Fin` of a number, which the trace adds up term by term, has
+  the facts of its terms' accesses stated once, over its binder, as the
+  source writes the access (#181, #223): S1's `contravariant` reads
+  `G[3*x + d, e, k, j, i] is in bounds for every x in Fin(3) and every
+  instance of S0`, where it listed `G[0 + d, ...]`, `G[3 + d, ...]` and `G[6 +
+  d, ...]`, and the three sums over `c` of `gradient_along_t` are one
+  exactness row, `for every d in Fin(3)`. The term, and the code, still
+  add the terms one by one. S1's ledger is 80 facts where it was 96, with
+  the same verdicts.
+- **A cast's fact id leaves out the target.** What a step means is the same
+  on every target, so the id of a cast's facts is the kernel's definition and
+  the steps (`cast:spmv.spmv@102:split('j', 2, ...):bijective`), and a
+  schedule retargeted (`fused.retarget("opencl").tag(i="g.0")`) shares the
+  facts of the steps it replays with the one it came from: a ledger lists
+  each fusion once. A `buildable` fact and a run's agreement keep the
+  target (`agreement:...:[c].split(...)`).
+- **A substitution through an array computed from inputs alone.**
+  `Schedule.substitute` computes an array where it is read from what its
+  producer read, and refused one whose producer reads an array an earlier
+  substitution computes where it is read, since the dependences of that
+  array's own reads were carried to a statement that no longer runs. Where
+  that array is computed from arrays nothing in the program writes (its
+  inputs), there are none, and the chain is substituted: grudge's `v.n`
+  from the normals, read by the upwind flux, read by the lift
+  (`examples/advection.py`). A chain through an array something writes is
+  refused as before.
+
+- `contract` of a program's array over a domain names `substitute` as the
+  other fix only where one statement stores the array, which is what a
+  substitution computes again; the flagship's triangles, which two
+  statements store, are refused with `keep it whole`.
+
+- A kernel's postcondition that its statements' stores decide reads
+  `decided isl` where it read `tested native`, after a new `single-assignment`
+  row, and the restatements of it in programs are worth `decided`; the
+  ledger of a file with schedules at module level lists their casts, a
+  window's `no-clobber` and an atomic step's reassociation among them. The
+  `definedness` fact a substitution or a window asks of a schedule leads
+  with its step, `for substitute('f'), every cell of f that burgers_rhs
+  reads, flux.S0 has stored by the time it is read`, so that the two rows of
+  `examples/fusion.py`, one per step after one fusion, read apart. The
+  transcripts in the documentation are regenerated.
+- `loopty.hypotheses.discharge` names a universal hypothesis's binders apart
+  from the claim's own names before taking it at the claim's cells: an
+  instance at the claim's `r` of a hypothesis over `r` was left out, which
+  lost a verdict.
+- Where Lean is installed, a rewritten layout's facts are proved
+  ([#186](https://github.com/xywei/loopty/issues/186)): one decided by the
+  row starts is stated as the induction step, each write of the offsets
+  storing the value its cell holds where they start at 0 and step by the
+  counts, as the contract checks on entry; one decided by induction over the
+  run, as each write's question under the order before it. And a
+  substitution's `definedness` fact and the casts after a substitution are
+  proved ([#187](https://github.com/xywei/loopty/issues/187)): the reads a
+  substitution computes again are stated as reads of what the producer read,
+  at the instance that stored the cell, ordered against every write of it,
+  and the statements it took out are in no class. So every fact isl decides
+  about the examples is now stated for Lean, and the coverage report in
+  `docs/lean-checks.md` is rerun. A claim decided under hypotheses is given
+  up to 32 of isl's instances of them, where it was given 16.
+- `substitute` refuses an array kept in a window, and `contract` one
+  computed where it is read.
+- The coverage report in `docs/lean-checks.md` covers the demos' examples
+  (`l2p.py`, the flagship, `assembly.py`, `hexahedra.py`,
+  `layer_potential.py`, `advection.py`, `quadrature.py`,
+  `sum_factorization.py`), `storage_layouts.py`, `taylor_reconstruction.py`,
+  the calls in loops (`examples/calls.py`, `tests/kernels/calls.py`,
+  `tests/kernels/program_domains.py`), the upstream test kernels
+  (`tests/kernels/upstream.py`), the test kernels of programs'
+  postconditions, of reals at their class and of series
+  (`tests/kernels/program_posts.py`, `reals.py`, `series.py`), and the
+  windows, updates, layouts, postconditions decided from what kernels store
+  and cited theorems above: of 1584 facts isl decides in 34 files, Lean
+  proves 1521 and confirms the counterexample of 37 of the 38 refuted ones;
+  the other, two updates of one cell at the same time in `advection.py`, is
+  stated for isl only. The 25 it leaves decided are claims about reals,
+  which core Lean has no words for; with Mathlib it proves them too, 1546 in
+  all, and none stays decided. `examples/layer_potential.py` has 32, all
+  proved with Mathlib. `examples/l2p.py` has 48: 46 proved with Mathlib, and
+  its refused interchange and window of one row, whose negations Lean
+  proves.
+- A ledger gains a `definedness` row for each array a kernel reads only where
+  it wrote it before (`scan`'s `off`, `p2p`'s `term`, `pairs`' `f`), and an
+  access with mixed subscripts is decided where it was assumed; the
+  transcripts in the documentation are regenerated.
+- The questions isl answers (`Empty`, `Subset`, `Bijective`, `Monotone`)
+  carry a `lean` field, how the fact is stated for Lean, and a schedule's
+  cast facts have a `Cast` as their term where they had none (a
+  substitution's definedness fact an `IslOnly`, which says why Lean is not
+  asked).
+- The tests run with lanky's Lean oracle off, as CI runs them, but the ones
+  marked `lean` (`tests/test_lean_checks.py`), so that the suite passes where
+  Lean is installed and proves what the other tests read as `decided isl`.
+  Those hold the printer to its safeguards: non-vacuity of every part of
+  every example and test kernel, arrays given as tables; a mutation matrix of
+  the stencil's subscripts, guard and schedules, where Lean has to fail on
+  exactly the dependence classes isl finds reversed; and a differential of
+  every domain and every in-bounds goal's cells against isl's membership.
+- A cell set's dimensions are named apart from the loops of the access it is
+  built for, so that a ragged row's bound written in a loop called `a0`
+  reads back as that loop.
+- A step that runs two updates of one cell at the same time is refused with
+  a `disjoint-writes` fact of the step, where a `monotone` fact named the
+  pair before. That fact is stated for isl only, with the reason
+  (`docs/lean-checks.md`, #201). A `monotone` cast is stated for Lean without
+  the pairs of updates of one cell, which need no order; a cast with no pair
+  left is one trivial part.
+- Fewer indices than an array has axes, `A[i]`, are a row of it in a kernel
+  body, and an array of indices, `u[cell[c]]`, the cells it picks: a view a
+  called kernel takes, natively the row as an `Arr` sharing the buffer and
+  the gathered cells as a read-only copy, where both were refused as an
+  operation on the whole array. Used as a value, a view is still refused,
+  with the loop nest to write. A row of the cells a gather picks,
+  `u[cell][c]`, is `u[cell[c]]`, as numpy reads it. A table's row, `PHI[q]`,
+  reads natively as a read-only array, and as zeros out of range under a
+  false guard, as a cell does.
+- In a program's body, `x.dom.size` (and `x.dom[0].size`) is the size of an
+  axis of the argument, for the arrays it makes; iterating `x.dom` is still
+  refused, as a loop whose trip count is an argument. A kernel's contract
+  reads a size of its declared domain off the bounds of an argument's
+  binders, where the argument was built over a domain of other names.
+- A kernel that returns a value without declaring its sort, `-> Real`, is
+  refused when traced, naming the sort to declare; its value was dropped by
+  the compiled kernel.
+- Two array parameters a kernel only reads may share storage, `dot(x, x)`
+  or the diagonal of a Gram matrix: reads do not race, and both runs read
+  the same values. The contract still refuses two that share storage where
+  the kernel writes either; a native call traces the body to know which
+  it writes, only when two of its arguments share storage.
+- A schedule step that names no loop of the kernel lists its loops, and
+  names a called kernel's loop that was renamed when it was inlined:
+  `fill's loop n, inlined at ..., is n_0 here`.
+
+### Fixed
+
+- **An `ilp` loop around a sum runs its lanes in one loop of the sum
+  (#264).** A sum's domain named every loop around its statement, and loopy
+  opens a sum's loop inside every loop its domain names, so
+  `split("q", 3).tag(q_inner="ilp")` around `reduce_sum(... for b in
+  Fs.dom[q, j])` gave each lane a loop over `b` of its own, and the lanes
+  ran one after another. The domain now names only the loops its bounds
+  read: over a box, the loop over `b` holds the three lanes' updates, as
+  plain loopy writes it, while a triangle's `j < i + 1` keeps its sum in the
+  loop it reads, and a ragged row's length keeps every loop. The facts are
+  the term's and do not change. The launches of S1's "fields three at a
+  time" shape are now plain loopy's code up to loop names, and every other
+  shape's code is what it was; sumpy's tile on C in
+  `examples/layer_potential.py` runs the sources' loop once around its 16
+  targets, where it ran it once per target. Note 32 in
+  `docs/loopy-notes.md` has the details.
+- **A program's zeros on a device** (#255, #261). A program zeroes each array
+  it makes in a statement of its own, in loops the lowering names (`i_2`,
+  `i_5`), which ran on every work item: `fused.tag(i="g.0")` was refused at
+  `C.zeros`, and the schedule that was timed tagged `i_2` and `i_5`, names the
+  file never wrote. The zeros' loop along an axis of the array now goes on
+  the axis of the loop that every statement storing the array stores it
+  along, so each work item zeroes the cells it stores, before it stores them,
+  and the work-item check asks about the zeros as about any statement.
+  Where a crossing is a call's and the zeros', the call's is named. Zeros
+  that cannot follow (the array stored along a split loop, or along loops on
+  two axes) stay on every work item, and the refusal says why and that
+  `contract` or `substitute` drops them (#289). grudge's weak gradient in one launch,
+  every node on a work item of its own, is now refused for the row the pass
+  along `r` reads from other work items, not for the zeros of `w`.
+- On OpenCL, a complex number to a natural power below 100 is the products
+  numpy's power by an integer takes (`z * ((z * z) * (z * z))` for 5), never
+  pyopencl's `cdouble_powr`. loopy writes only the powers by 2, 3 and 4 as
+  products, and by 1 or 5, which a written-out series has, `exp(n log z)`:
+  a logarithm and an exponential for each, and not exact for `z**1`.
+- A schedule's `ilp` or `vec` tag no longer has loopy warn, on every build,
+  that it falls back to its first scheduler, which it does for every kernel
+  with such a loop: the tag silences `v1_scheduler_fallback` on the kernel
+  it makes. The warning opened `python examples/assembly.py` and
+  `python examples/layer_potential.py` on a fresh checkout.
+- An array of several axes read only through an index array,
+  `coords[cell[c, k], d]` with `nv` in no loop bound, is declared with its
+  strides, `stride:2,stride:1`, so that loopy indexes its rows; it was
+  declared without a shape, and loopy refused the read.
+- An access with mixed subscripts that a statement reads twice over one
+  domain, `x[0, 0]` read for two entries of an inlined Jacobian, is one
+  place, decided by isl; it was `assumed`.
+- A schedule's assumption is named `assume('nc % 4 == 0')` in the status of
+  the casts that rest on it (with lanky's `label`), where its whole id was.
+- **Two statements' atomic updates of one cell asked loopy for a global
+  barrier.** `y[p] += a[p]` and `y[p + 1] += a[p]` with `p` on `l.0` race
+  on `y[p + 1]`, and after `atomic("y")` the schedule is legal and its
+  `buildable` fact holds, but the lowered kernel kept the source's order of
+  the two, so loopy refused to generate it (`MissingBarrierError`). Once an
+  array's updates are atomic, the order is drawn again from the dependences
+  the casts are checked against, and two updates no dependence joins need
+  no order (loopy's `no_sync_with`): libParanumal's lift onto the face nodes
+  (`examples/advection.py`).
+
+- A write through a cell read from an array, `y[perm[i]] = x[i]`, no longer
+  has its distinct writes refuted by isl with two instances that write no
+  common cell. The fact is decided on the kernel's native runs instead. It is
+  refuted with two instances that write one cell on an input, the example
+  inputs first: `S0[c=0, k=2] and S0[c=1, k=1] both write y[3] on
+  example_inputs() (nc=2, nv=4), where cell[0, 2] = 3 and cell[1, 1] = 3`.
+  Where no input has such a pair, as for `y[i, p[i]]`, it is `tested`.
+- The first run of a kernel with an array of four axes over one size, or a
+  triangle boxed over two, no longer prints loopy's `ParameterFinderWarning:
+  Unable to generate code to automatically find 'm' from 'u': nonlinear
+  expression`, a warning about an equation of the strides loopy's invoker
+  could not solve, while it found the size from the shape (note 28 in
+  `docs/loopy-notes.md`). Five constructs kernels written like sumpy's L2P
+  and grudge's sum-factorized passes need, a
+  `Where` array beside a ragged family, a `Where` of three binders, `**` with
+  a loop variable as the exponent in a sum of two binders and in a sum
+  nested in another, four dense axes and `when(a + b == 0)`, were run three
+  ways and work; `tests/test_demo_shapes.py` keeps them so.
+- A split sum adds its terms in order. `split("s", 256)` of a sum's loop
+  left loopy to choose the order of the two loops it makes, and loopy ran
+  the inner one outside, `for s_inner ... for s_outer`, adding every 256th
+  term first: another sum in floating point, `2**53` where the native run
+  adds `1 + 1 + 2**53` to `2**53 + 2`. Every schedule now gives loopy a sum's
+  loops in order, outermost first, as it gives it each statement's nest.
+- `fuse` after a `split` or a `tile` of the producer's outer loop is no
+  longer refused as unbuildable. The producer's domain is cut after the fused
+  loops by name, not by position: loopy 2025.2 puts a split loop's two after
+  the others, `[j, i_outer, i_inner]`, so
+  `Schedule(squared_rows).split(i, 2).fuse("square2", "row_total")` read
+  `buildable` refuted though both casts were decided
+  ([#192](https://github.com/xywei/loopty/issues/192)).
+
 ## [0.2.0] - 2026-10-11
 
 The second release, on lanky 0.2.0, which checks each theorem's reading of