loopty 0.1.0__tar.gz → 0.2.0__tar.gz

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

@@ -6,6 +6,191 @@ All notable changes to loopty are recorded here. The format follows
 
 ## [Unreleased]
 
+## [0.2.0] - 2026-10-11
+
+The second release, on lanky 0.2.0, which checks each theorem's reading of
+its annotations and gives it a row of its own in the ledger, and whose `abs`
+of a term compares (lanky#94); loopty requires it, so that the ledgers its
+documentation shows are the ones an install prints. The rest is two waves of
+fixes where the compiled run computed otherwise than numpy, or did not build:
+subscripts, storage and names (#164: an index sum in a dividing subscript is
+64 bits wide, a narrow subscript stays in its type, complex `==` builds on
+OpenCL, a program's arrays are off the C stack, and every isl dimension
+loopty names has a name of its own), and arithmetic and messages (#169: a
+sum is computed as the body wrote it, `abs` of a real lowers in a guard, the
+compiled run is refused before it starts where the native run is refused,
+and loopy's refusal of a guard it cannot read names the fix). CI also tests
+loopty against the released lanky (#160). The README's Known limits section
+lists what is still open.
+
+### Added
+
+- **The names of isl dimensions** (`loopty.names`, #161). Every isl object
+  loopty names the dimensions of keeps namedisl's invariants: each
+  dimension has a name, no two share one, and none is named like a
+  parameter. isl's reader breaks them silently, reading a tuple variable
+  spelled like a parameter as that parameter (#110). `check_names` checks
+  them where such an object is made, a statement's and a sum's domain when
+  the term records it, the loops of a nest, an access relation (its cells
+  are positional), the index tuples of a shape, a dense layout's map and a
+  polyhedral domain's points, and raises `NamingError`, a bug of loopty's,
+  naming the object and the clash. `rename` is the one way loopty renames
+  dimensions and replaces parameters, all at once: composing a program
+  (`compose.rename_set`), the binders of a nested sum in the lowering, and
+  the native run fixing a parameter at the value it reads use it.
+
+### Changed
+
+- **Requires lanky 0.2.0** (`lanky>=0.2.0`, was `>=0.1.0`). Its ledger has
+  a reading row under each theorem (the next entry), which the `lanky check`
+  transcripts in the README, the quickstart and the examples' README show,
+  and its `abs` of a term is lanky's `Abs`, so a comparison of it traces,
+  `when(abs(k[i]) > 2)` and `127 == abs(c[i])` (lanky#94); the test of that
+  (#165) no longer skips on an older lanky. `[tool.uv.sources]` still
+  resolves lanky from `../lanky` in a checkout, and the built distributions
+  ask for it from PyPI.
+- **A theorem in a kernel file has its reading under it** (lanky #91, #155).
+  lanky now checks each claim's reading of its annotations: the annotations
+  are run again as plain Python at drawn values, the term is evaluated at the
+  same values, and the two have to agree. Each theorem gets a second fact,
+  `tested python ... the term computes what the annotations compute`, on
+  which its pass or proof rests. The `lanky check` transcripts of
+  `examples/spmv.py` and `examples/travel.py`, each of which has a
+  `scan_monotone`, show the new row, and are regenerated with
+  `scripts/refresh_example_outputs.py`; `examples/README.md` says what the
+  row is. A kernel's and a program's facts are loopty's, and have no such
+  row: their trace has its own check, `trace-faithful`. (This entry was
+  filed under 0.1.0 by mistake; it was merged after that release.)
+- CI also tests loopty as `pip install loopty` gets it: a second job installs
+  it without `[tool.uv.sources]`, so with lanky from PyPI, and runs the suite
+  and the worked example's `lanky check` and `loopty run` (#147).
+- loopy's refusal of an access under a guard its bounds check does not read,
+  a product of loop variables, a guard computed in floating point or an
+  array's entry, names the statement, where the body wrote it, the guard,
+  and a guard over integers that keeps the access in bounds, which loopy
+  reads, with a size as the body reads it: `with when(i <= y.dom.size - 5):`
+  for `x[i + 4]` under `when(i * 0.5 < 2)` (#148). It is
+  `loopty.refusal.GuardNotRead`, a `LoopyIndexError` still, with loopy's
+  message at its end. A guard that calls a function no statement's value
+  calls, which loopy never resolves, is refused with a `LoweringError`
+  naming the fix, where loopy failed with `KeyError` and the function's
+  name.
+- An array a program makes is off the C stack (#62). On the C target loopy
+  declared it a variable-length array on the stack of the call, `double
+  f[n];`, so the thread's stack bounded how large an intermediate could be,
+  and a program whose intermediate was larger, eight megabytes on a thread
+  with four, died with no diagnostic. `LoopyExecutor` now allocates it on
+  the heap, zeroed, and passes it after the program's own arguments,
+  `double *__restrict__ f`, and `emit_code` and `loopty run --emit-code`
+  print it so (`lower.heap_temporaries`). The term and its schedules keep it
+  a temporary, which `Schedule.substitute` computes away; an empty one stays
+  where it takes no room, since loopy's C invoker cannot pass an empty
+  array. The OpenCL target's global temporary is unchanged.
+
+### Fixed
+
+- A sum is computed as the body wrote it (#151). pymbolic builds `a - b` as
+  `a + -1 * b` and `u - 1` as `u + -1`, the same nodes `a + -b` and `u + -1`
+  build, and the trace, the plan and the interpreter read every such sum as
+  the difference, which numpy computes otherwise: `c[i] + -a[i]` of an `int8`
+  `a` is `c[i] + -128` at `a[i] = -128` natively and was `c[i] + 128`
+  compiled, and `c[i] + -u[i]` of a `uint8` `u` adds `256 - u[i]` natively
+  and subtracted `u[i]`, at every `u[i]` but zero. The trace builds every `-`
+  the body writes as a `loopty.term.Difference`, a sum whose last term is
+  subtracted, and any other sum is read as written. So `u[i] + -1` of an
+  unsigned `u`, `k[i] - 2**31` and `k[i] + 2**31` of an `int32` `k`, `u[i] -
+  -7`, `c[i] + -b[i]` and `b[i] - True` of a truth value `b`, which numpy
+  refuses at every point and the compiled run computed as the other
+  spelling, are `TraceError`s naming the fix, and `k[i] + -(2**31)` and
+  `c[i] - -32768` of an `int16` `c` are computed in the type numpy computes
+  them in. A numpy scalar subtracted is kept as written, where pymbolic negates it
+  in its own type: `k[i] - np.uint8(3)` was `k[i] + 253` compiled. The
+  smallest `int32` and `int64` are written as C writes `INT_MIN`,
+  `(-2147483647 - 1)`: `-2147483648` is the negation of a `long` in C, and
+  `k[i] + -2147483648` of an `int32` `k` was computed in 64 bits, never
+  wrapping round as numpy does; `-9223372036854775808` is the negation of a
+  constant no signed type holds, which GCC reads in 128 bits with a warning
+  and clang as an `unsigned long`. That is on the C target, built with
+  `-fwrapv`; OpenCL C has none, and its compilers fold `k[i] + (-2147483647 -
+  1)` into `k[i] | (-2147483647 - 1)`, so there the literal is left as loopy
+  writes it. A real less an integer keeps the sign of zero: `x[i] - 0` and
+  `x[i] - i`, `-0.0` natively at `x[i] = -0.0` and `i = 0`, were `0.0`
+  compiled, since pymbolic builds them as `x[i] + 0` and `x[i] + -1 * i`; the
+  zero is written `-0.0`, and `i` is converted into the real's type before it
+  is negated. A truth value subtracted, `k[i] - True`, which pymbolic takes as
+  no operand, is a `TraceError` naming the integer, `k[i] - 1`. `k[i] - 2**63`
+  and `b[i] - 2**63` of a truth value `b`, which numpy refuses in `int64`, are
+  refused by the trace, naming a real, `2.0 ** 63`.
+- `abs` of a real in a guard lowers (#154): loopy's type inference visits a
+  statement's value and never its guard, so `abs`, which only the guard
+  called, was never resolved, and loopy failed with `KeyError: 'abs'`. In a
+  guard it is written `x < 0 ? -x : (x == 0 ? 0 : x)`, which is numpy's
+  `abs(-0.0)` too, `0.0`.
+- Loop arithmetic beside a numpy integer whose type does not hold it at a
+  point of the loops, `u[i] + (i - 3)` of a `uint32` `u` at `i = 0`, `a[i] *
+  (i * 100)` of an `int8` `a` from `i = 2`, and a loop variable stored into an
+  `int8` array from `i = 128`, is refused by numpy natively there, and the
+  compiled run computed it in C's type (#153). Where the call's sizes reach
+  such a point, isl finds it, and the compiled run is refused before it
+  starts (`loopty.refusal.RefusedNatively`, an `OverflowError`), naming the
+  point and `(i - 3) * np.int64(1)` as the fix. Arithmetic isl cannot read,
+  or a ragged row's loop, is left to the native refusal (#166). A sum's body
+  is asked about where the generator's `if` clause holds, which skips it
+  natively: `reduce_sum(a[j] + j for j in a.dom if j < 100)` of an `int8`
+  `a` is computed at any size. A program's call after a checked point is
+  refused once the run has shown that the points before it passed, whatever
+  a point after it says; where one before it failed, that point's error is
+  raised, as natively. A literal stored into an integer array that does not
+  hold it, `y[i] = 300` of a `uint8` `y`, is a `TraceError`, as #141's
+  literals are; under a guard, which masks the store, it is refused where the
+  call's sizes reach a point of the guard, and `with when(i < 0): y[i] = 300`
+  stores nothing in either run.
+- A regression test for #152, which #156 fixed: a literal beside a loop
+  variable under a double power in a single-precision statement is written as
+  an integer, `(double) (i + 16777216)`, where loopy wrote `1.0f` and C
+  rounded the loop variable past `2**24`.
+- A sum of loop variables and sizes in a dividing subscript is computed in
+  64 bits (#149). The plan leaves such a sum in 32 bits, as loopy computes a
+  loop bound, and a remainder or a floor division in a subscript used the
+  wrapped value once the sum passed `2**31`: `x[(i + k) % m]` at `k = 2**31 -
+  1` read cell `(-2**31) % 3` at `i = 1`, where numpy reads `2**31 % 3`, and
+  loopy wrote `x[(i + n) // 2]`, which it reads as affine with a division,
+  as `x[(i + n) / 2]`. In a subscript loopy does not read as affine with no
+  division the sum's first operand is widened now,
+  `x[loopty_mod_int64((int64_t) (i) + k, (int64_t) (m))]`, and `abs` of one
+  takes its sign from bit 63. The same sum in a value or a guard on the
+  loops is still 32 bits wide (#162).
+- A subscript over a narrow numpy integer type is computed in it, as numpy
+  computes it (#157). The conversion back into `int8`, `uint8`, `int16` or
+  `uint16` that an operation in such a type gets elsewhere (#122) was left
+  out of a subscript, so `x[s + i]` of a `uint8` `s`, which loopy reads as
+  affine, read cell 256 where numpy takes `250 + 6` round to 0, and
+  `x[abs(s) % 7]` of an `int8` `-128` read cell 2, where numpy's `abs` keeps
+  `-128`, whose remainder is 5. It is kept now, `x[(uint8_t) (s + i)]`, and
+  loopy's reader declines the cast, so the subscript is written as it is.
+- `==` and `!=` of complex values build on the OpenCL target (#158).
+  pyopencl's complex types are structs, which OpenCL C does not compare, and
+  loopy wrote `z[i] == w[i]` as it is, so the kernel did not build. They are
+  compared part by part, as numpy compares, in the complex type of the two,
+  a real operand with a zero imaginary part: `cdouble_real(z[i]) ==
+  cdouble_real(w[i]) && cdouble_imag(z[i]) == cdouble_imag(w[i])`. The C
+  targets compare C99's complex types with C's operators, as before.
+- The index tuples of a shape whose size is named `i0`, `idx.to_set((Fin[i0],
+  ...))`, had no points: their dimensions were named `i0, i1, ...` whatever
+  the sizes are called, and isl read the dimension `i0` as the size, `0 <= i0
+  < i0`. They are named clear of the sizes now, as a polyhedral domain's
+  already were (#161).
+- A sum by a binder named like a size or an integer parameter of the kernel,
+  `reduce_sum(x[j] for j in x.dom)` over `x: Arr[Fin[j], Real]`, is refused
+  at the trace, naming the fix (#161). Its domain was `{ [j] : 0 <= j < j }`,
+  a set with a well-named dimension and no points, which the name check
+  could not see: the compiled sum was `0` where numpy's was not, the
+  in-bounds fact of `x[j + 5]` was decided over the empty domain, and a sum
+  by `i` inside a loop bounded by a size `i` did not build. A loop variable
+  so named was already given a name of its own. `flow.domain_set` and a
+  polyhedral domain's points now also refuse a dimension named like a size
+  their bounds meant as a parameter (`check_names(..., meant=...)`).
+
 ## [0.1.0] - 2026-10-09
 
 The first release on PyPI, where only the 0.0.1 placeholder that reserved the

{loopty-0.1.0 → loopty-0.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: loopty
-Version: 0.1.0
+Version: 0.2.0
 Summary: loopy, with types. A typed polyhedral layer over loopy.
 Project-URL: Homepage, https://github.com/xywei/loopty
 Project-URL: Repository, https://github.com/xywei/loopty
@@ -25,7 +25,7 @@ Classifier: Topic :: Software Development :: Compilers
 Classifier: Typing :: Typed
 Requires-Python: >=3.12
 Requires-Dist: islpy<2026,>=2025.2.5
-Requires-Dist: lanky>=0.1.0
+Requires-Dist: lanky>=0.2.0
 Requires-Dist: loopy<2025.3,>=2025.2
 Requires-Dist: numpy>=2
 Requires-Dist: pymbolic>=2025.1
@@ -90,7 +90,7 @@ decided  decided    type           spmv.py:112  spmv           the accumulation
 tested   tested     interpreter    spmv.py:102  spmv           the traced term computes what the body computes
 decided  tested     call           spmv.py:115  solve          after scan(...) in solve: off[0] == 0 and (forall r in Fin(n). off[r ...
 ...
-21 facts: 16 decided, 5 tested
+22 facts: 16 decided, 6 tested
 ```
 
 Look at the `x[col[r, j]]` row, and at what decided it. That indirection is the
@@ -254,17 +254,19 @@ table of row starts. Both compiled runs agree with the native one.
 
 ## Status
 
-This is 0.1.0, the first release. The core works: kernels and programs run
-natively, trace, state their facts, lower and run compiled on the C target,
-and every schedule step is checked; the edges are sharp. Below is what works,
-what works in part and what does not work yet, and after it, under Known
-limits, the open issues you are most likely to meet, one of them a fact the
-ledger calls `decided` that is false: read that before you rely on a ledger.
-CI runs the suite on every change, on Python 3.12 and 3.13 and against lanky's
-`main`, and reruns every command whose output this README, the quickstart and
-the examples' README show, holding them to what it prints. It runs no OpenCL
-device. Until 1.0 an interface can change in a minor release; the CHANGELOG
-says when one does.
+This is 0.2.0. The core works: kernels and programs run natively, trace,
+state their facts, lower and run compiled on the C target, and every schedule
+step is checked; the edges are sharp. Below is what works, what works in part
+and what does not work yet. After it, Known limits lists the open issues you
+are most likely to meet, each with what to do about it. None of them makes the
+ledger call a false fact `decided`, but in several the compiled run computes
+something other than the native run, and the ledger catches that only on the
+inputs it tries: read that section before you rely on a compiled run. CI runs
+the suite on every change, on Python 3.12 and 3.13 with lanky's `main` and on
+3.13 with the released lanky, and reruns every command whose output this
+README, the quickstart and the examples' README show, holding them to what it
+prints. It runs no OpenCL device. Until 1.0 an interface can change in a minor
+release; the CHANGELOG says when one does.
 
 **Works.**
 
@@ -350,7 +352,11 @@ says when one does.
   loop variables, a float literal or a `Real` scalar (`when(i * 0.5 < 2)`,
   `when(i * 2.0 < n)`), it checks an access at every point of the loop, and
   refuses one it cannot show in bounds there, one the guard keeps in bounds
-  included (#148; note 23 in `docs/loopy-notes.md`). A guard has to be a truth value, and one whose
+  included. The refusal (`loopty.refusal.GuardNotRead`, a `LoopyIndexError`)
+  names the statement, the guard, and a guard over integers that keeps the
+  access in bounds, as the body writes it, `when(i <= y.dom.size - 5)` for
+  `x[i + 4]` (#148; note 23 in
+  `docs/loopy-notes.md`). A guard has to be a truth value, and one whose
   value is an integer is a `TraceError`, on a native run and under tracing
   alike. Natively
   that is what `~(i > 0)` is (`~` on a Python bool is bitwise), while the trace
@@ -486,10 +492,25 @@ says when one does.
   back into it, and an unsigned integer beside a signed one is computed in
   the signed type numpy computes in (`int64` for a `uint32` and an `int32`),
   where C's would be unsigned; integers compare exactly, as numpy's do, a
-  negative one with an unsigned one included. `abs` of an integer is numpy's,
-  the smallest value of its type included; a comparison of one does not
-  trace yet (`abs(k[i]) > 2`, xywei/lanky#94). An integer literal past 64 bits
-  is written as a real where numpy computes in one (`x[i] * 2**70`), or as a
+  negative one with an unsigned one included. A sum is computed as the body
+  wrote it: `c[i] - a[i]` as the difference, and `c[i] + -a[i]` as the sum of
+  `a[i]` negated in its own type, which differ for an `int8` `a` at `-128` and
+  an unsigned one at every value but zero; `u[i] + -1` of an unsigned `u` and
+  `k[i] - 2**31` of an `int32` `k`, which numpy refuses at every point, are
+  refused by the trace (#151). A real less an integer keeps the sign of zero,
+  `x[i] - 0` and `x[i] - i` at `x[i] = -0.0`, and a truth value subtracted,
+  `k[i] - True`, which pymbolic takes no operand of, is refused naming the
+  integer. Loop arithmetic beside a numpy integer whose
+  type does not hold it at some point, `u[i] + (i - 3)` of a `uint32` `u` at
+  `i = 0`, is refused by numpy natively there, and the compiled run is refused
+  before it starts where the call's sizes reach such a point, naming it
+  (`loopty.refusal.RefusedNatively`, #153). `abs` of an integer is numpy's,
+  the smallest value of its type included, and `abs` of a real in a guard is
+  written without a call, since loopy resolves no function only a guard calls
+  (#154); another function only a guard calls is refused, naming the fix.
+  `abs` of a term compares on either side, `when(abs(k[i]) > 2)` and `127 ==
+  abs(c[i])`, since lanky 0.2.0 (xywei/lanky#94). An integer literal past 64
+  bits is written as a real where numpy computes in one (`x[i] * 2**70`), or as a
   `uint64` beside one (`u[i] + 2**63`), and refused elsewhere. A kernel named
   like a function, a macro or a type loopy, the C headers or OpenCL C know
   (`floor`, `pow`, `cpow`, `get_global_id`, `clamp`, `NULL`, `size_t`) is
@@ -636,11 +657,12 @@ says when one does.
   what the compiled temporary holds: `float64` for `Real`, the dtype itself
   for a numpy one such as `np.complex128`, `bool` for `Bool`, `int64` for
   `Nat` and `Int`, and a signed integer of 32 bits or more for `Fin[m]`
-  (`int64` for an array a checked point reads). On the C target a
-  temporary is a variable-length array on the stack of the call, which bounds
-  its size (note 16 in `docs/loopy-notes.md`); on OpenCL it is a global
-  temporary, which is generated but, like every device path, not run from a
-  development machine.
+  (`int64` for an array a checked point reads). On the C target the executor
+  allocates a program's array on the heap and passes it after the program's
+  own arguments, `double *__restrict__ f`, where loopy would declare it on
+  the stack of the call, whose size bounded it (#62; note 16 in
+  `docs/loopy-notes.md`); on OpenCL it is a global temporary, which the
+  PyOpenCL host code allocates.
 - Only a two-axis (row, fiber) ragged array, its rows counted by an array of
   one axis, is built and lowered; tracing refuses any other ragged type, a
   fiber after two dense axes, a dense axis after the fiber, or counts of two
@@ -651,28 +673,43 @@ says when one does.
   which is exact: `1.0 * i ** 5` past `i = 6208` is a wider number natively
   and wraps compiled, which the differential fact reports (#139).
   A loop bound, and a subscript loopy reads as affine with no division, are
-  loopy's index arithmetic, 32 bits wide, and so is a sum of loop variables,
-  sizes and small literals elsewhere; under `-fwrapv` such a subscript's
+  loopy's index arithmetic, 32 bits wide; under `-fwrapv` such a subscript's
   sums and products give the cell it names. Any other subscript is computed
-  in 64 bits, as the rest is: `x[(i * i) % n]` (#129), and `x[(i * 499999)
-  // 1000000]`, which loopy wrote with a division of the wrapped `499999 *
-  i`. A sum the plan leaves in 32 bits stays so in a division too, `x[(i +
-  n) // 2]` past `2**30` (#149). A subscript over a narrow numpy integer
-  type is not converted back into it (#157). A `Fin[m]` array the kernel
-  writes may be an `int32` one natively, whose entries the native run reads
-  as `int64`, as the compiled run computes with them, unless a program's
-  checked point reads it, which takes an `int64` one. An integer to a
-  negative power whose exponent is not a literal is left to numpy's refusal
-  natively, and computed as an integer compiled. pymbolic builds `u[i] - 1`
-  and `u[i] + -1` as one term, read as the difference: of an unsigned `u`
-  numpy refuses the second at every point, and the compiled run computes it
-  as the first; `a - b` and `a + -b` of an `int8` `b` likewise differ
-  natively at `b = -128` alone, and of an `Int` `a` and an unsigned `b` at
-  every `b` but zero (#151). A loop variable's arithmetic beside
-  a numpy integer whose type does not hold its value at some point,
-  `u[i] + (i - 3)` of a `uint32` `u`, is refused natively there and
-  computed compiled (#153), and `abs` of a real in a guard fails inside
-  loopy (#154). See notes 19, 20 and 23 in `docs/loopy-notes.md`.
+  in 64 bits, as the rest is, its sums of loop variables and sizes included:
+  `x[(i * i) % n]` (#129), `x[(i * 499999) // 1000000]`, which loopy wrote
+  with a division of the wrapped `499999 * i`, and `x[(i + n) // 2]`, whose
+  sum wrapped round past `2**30` (#149). A sum of loop variables, sizes and
+  small literals in a value or a guard on the loops is still 32 bits wide,
+  `y[i] = i + n` past `2**31` (#162). A subscript over a narrow numpy integer
+  type is computed in it, as numpy computes it: `x[s + i]` of a `uint8` `s`
+  wraps round at 256 in both runs (#157). One of a signed type that wraps
+  round below zero is refused natively, as any negative index is, and read
+  before the array compiled; its in-bounds fact is not decided, since isl
+  reads a narrow scalar or element as any integer, and is refuted or
+  assumed. A `Fin[m]` array the kernel writes may be an `int32` one
+  natively, whose entries the native run reads as `int64`, as the compiled
+  run computes with them, unless a program's checked point reads it, which
+  takes an `int64` one. An integer to a negative power whose exponent is not
+  a literal is left to numpy's refusal natively, and computed as an integer
+  compiled. Loop arithmetic beside a numpy integer that does not hold it is
+  refused compiled where isl reads it and the call's sizes fix its loops
+  (#153); a product of loop variables, a ragged row's loop, a store under a
+  guard isl does not read, and a sum's body under both a guard and the
+  generator's `if` clause where the guard is false, are left to the native
+  refusal and computed compiled (#166). So is a value stored into a signed
+  integer array that does not hold it, a `uint64` past `2**63` into `Int`,
+  an `Int` into an `np.int8` array, or a real past `2**63`, or a NaN, into
+  `Int`, whose value only the compiled kernel knows (#159). The written `-1 *
+  u[i]` of an unsigned `u`, which numpy refuses, is read as `-u[i]`, which
+  it computes (#168). A numpy scalar on the left of a term is traced as the
+  Python number it equals: `np.float64(0.1) * x[i]` as `0.1 * x[i]`, single
+  precision beside a `float32`, and `x[np.uint8(200) + i]` as `x[200 + i]`,
+  not taken round (#167). Two statements of one kernel whose lowered
+  arithmetic differs only by the dtype of an equal literal are generated
+  with the first one's literal, since loopy maps a subexpression to the
+  result of an equal one, and pymbolic finds a numpy scalar equal to any
+  number of its value (#170). See notes 19, 20, 23 and 25 in
+  `docs/loopy-notes.md`.
 - A polyhedral domain is an array's whole index set, so it cannot sit beside
   a dense axis (`Arr[Fin[k], Where[...], Real]` is refused; write the axis as
   a binder of the domain). The pieces of a union have the same number of axes,
@@ -819,51 +856,97 @@ says when one does.
 
 ## Known limits
 
-The open issues a user is most likely to meet. Each says what the ledger and
-the runs make of it, since that is what decides whether it can go unnoticed.
-
-- **Some index arithmetic is 32 bits wide compiled**
-  ([#149](https://github.com/xywei/loopty/issues/149), [#157](https://github.com/xywei/loopty/issues/157)). A loop bound, and a subscript loopy
-  reads as affine with no division, are loopy's index arithmetic, 32 bits
-  wide. Every other subscript is computed in 64 bits, as natively. A sum of
-  loop variables and sizes inside a dividing subscript stays in 32 bits, so
-  `x[(i + n) // 2]` wraps round past `2**30` (#149). A subscript over a
-  narrow numpy integer type, such as `int8` or `uint16`, is computed in C's
-  `int` compiled, and wraps round natively (#157).
-- **A guard loopy's bounds check cannot read**
-  ([#148](https://github.com/xywei/loopty/issues/148)). An access that only a floating-point guard keeps in
-  bounds, `x[2 * i]` under `when(i * 2.0 < n)`, is refused by loopy's bounds
-  check, with a message that names no fix. Write the guard over integers.
-- **Integers past 64 bits** ([#139](https://github.com/xywei/loopty/issues/139), [#159](https://github.com/xywei/loopty/issues/159)). Arithmetic of
-  loop variables, sizes and literals alone is exact natively and 64 bits wide
-  compiled: `1.0 * i ** 5` wraps round compiled past `i = 6208`, and the
-  differential fact is refuted. A `uint64` value past `2**63` stored into an
-  `Int` array is refused natively and wraps round compiled.
+The open issues you are most likely to meet, and what to do about each. Most
+show in `lanky check` or `loopty run` as a `refuted` or `assumed` fact or as
+an error, but `loopty run` compares the compiled run with the native one only
+on the inputs it runs.
+
+- **A compiled run does not check indices**
+  ([#171](https://github.com/xywei/loopty/issues/171)). `loopty run` and
+  `LoopyExecutor.run` compile a kernel whatever its in-bounds facts say. Where
+  an index leaves its array, the native run raises `IndexError` and the
+  compiled run reads or writes outside the buffer, with no error. `lanky
+  check` shows where this can happen: the access's row, `x[i + 4] is in bounds
+  for every instance of S0`, reads `refuted` or `assumed`. Put the access
+  under a guard isl can read, which decides the fact: `with when(i + 4 <
+  x.dom.size):` before `y[i] = x[i + 4]`.
+- **A numpy scalar on the left of an operation loses its type**
+  ([#167](https://github.com/xywei/loopty/issues/167)). `np.float64(0.1) *
+  x[i]` is traced as `0.1 * x[i]`, so beside a `float32` `x` the compiled run
+  multiplies in single precision where numpy uses double. The difference is
+  within the tolerance `loopty run` allows a `float32` input, so it reads
+  `tested`. Put the scalar on the right: `x[i] * np.float64(0.1)`.
+- **Loop arithmetic outside a subscript is 32 bits wide compiled**
+  ([#162](https://github.com/xywei/loopty/issues/162)). A sum of loop
+  variables and sizes used as a value, `y[i] = i + n`, `(i + n) // 2` or
+  `1.0 * (i + n)`, wraps round compiled once it passes `2**31`, which takes a
+  size past about `2**30`; natively it is exact. `loopty run` reports it only
+  on an input that large. Make the first operand a 64-bit integer:
+  `y[i] = i * np.int64(1) + n`. A loop bound and a guard on the loops,
+  `when(i + n > 5)`, stay 32 bits wide: keep their sums below `2**31`.
+- **Integers past 64 bits**
+  ([#139](https://github.com/xywei/loopty/issues/139)). Arithmetic of loop
+  variables, sizes and literals alone is exact natively, as Python's integers
+  are, and 64 bits wide compiled: `1.0 * i ** 5` wraps round compiled past
+  `i = 6208`, which `loopty run` reports on an input that reaches it. Where
+  you want a real, compute in one from the start: `(1.0 * i) ** 5`.
+- **Values too large for a narrow numpy integer**
+  ([#166](https://github.com/xywei/loopty/issues/166),
+  [#159](https://github.com/xywei/loopty/issues/159),
+  [#177](https://github.com/xywei/loopty/issues/177)). numpy raises when a
+  value does not fit an integer type such as `np.int16`, and loopty refuses a
+  compiled run before it starts wherever isl finds such a value at the call's
+  sizes. The check misses a product of loop variables, `a[i] + i * i` of an
+  `np.int16` `a`, loop arithmetic in a ragged row's loop, and a `uint64` past
+  `2**63` stored into an `Int` array: the compiled run wraps these round, and
+  `loopty run` raises the native run's error only on an input that reaches
+  one. It also refuses one case numpy completes, a sum whose `if` clause
+  repeats the statement's guard. In each case, widen the narrow value first,
+  `a[i] * np.int64(1) + i * i`, which both runs compute alike, and store a
+  `uint64` into an `np.uint64` array.
+- **A few spellings fail without naming the fix**
+  ([#172](https://github.com/xywei/loopty/issues/172),
+  [#173](https://github.com/xywei/loopty/issues/173),
+  [#175](https://github.com/xywei/loopty/issues/175)). A sum in a guard,
+  `when(reduce_sum(x[j] for j in x.dom) > 1)`, fails inside loopy with `name
+  already used as iname`: compute the sum into an array in a statement of its
+  own and read that array in the guard. A truth value first in arithmetic,
+  `True - k[i]`, fails while tracing with Python's `TypeError`: write the
+  integer, `1 - k[i]`. `k[i] - -(2**63)` of an `Int` is refused as a literal
+  past 64 bits, though numpy computes it: write `k[i] + -(2**63)`, the same
+  value in `int64`.
+- **A refused program has written its outputs**
+  ([#176](https://github.com/xywei/loopty/issues/176)). When a compiled
+  program raises `RefusedNatively` for a call that follows one of its checks
+  between calls, the whole program has already run: that call and the calls
+  after it have written their outputs, where natively the program stopped
+  inside that call. After the error, do not trust the arrays, and pass copies
+  if you need them as they were.
 - **What passes between calls is stored in full or not at all**
-  ([#132](https://github.com/xywei/loopty/issues/132), [#133](https://github.com/xywei/loopty/issues/133)). `Schedule.substitute` computes an
-  intermediate again at every read; keeping only the cells live at once, a
-  window of three cells of `f` after the Burgers fusion, is not done. Nor is
-  a substitution through two intermediates, one computed from the other.
-- **A program's intermediates live on the C stack**
-  ([#62](https://github.com/xywei/loopty/issues/62)). An array a program makes
-  with `Arr.zeros_like` is a variable-length array on the stack of the compiled
-  call, so one larger than the stack crashes the compiled run, and nothing
-  checks the size first.
-- **The OpenCL target is not run in CI.** `--target opencl`, with the `opencl`
-  extra, generates OpenCL and runs it through pyopencl, and nothing in CI or in
-  the test suite runs a device. The demos were run on two device classes by
+  ([#132](https://github.com/xywei/loopty/issues/132),
+  [#133](https://github.com/xywei/loopty/issues/133)). `Schedule.substitute`
+  computes an intermediate again at every read; storing only the cells live at
+  once, a window of three cells of `f` after the Burgers fusion, is not done.
+  A substitution through two intermediates, one computed from the other, is
+  refused: substitute one of them.
+- **The OpenCL target is not run in CI**
+  ([#174](https://github.com/xywei/loopty/issues/174)). `--target opencl`,
+  with the `opencl` extra, generates OpenCL and runs it through pyopencl, and
+  nothing in CI runs a device. The demos were run on two device classes by
   hand, and
   [docs/device-runs.md](https://github.com/xywei/loopty/blob/main/docs/device-runs.md)
-  has the commands and the transcripts. A comparison of complex values does
-  not build on it ([#158](https://github.com/xywei/loopty/issues/158)).
+  has the commands and the transcripts. Signed integer overflow is undefined
+  in OpenCL C, which has no `-fwrapv`, so a signed integer sum that
+  overflows, which numpy wraps round, can come out otherwise there: run such
+  a kernel on the C target.
 - **A theorem's or a postcondition's statement is lanky's reading of it.**
-  loopty traces a kernel's body itself, and the `trace-faithful` fact checks
-  that trace. A theorem, and the claim after a kernel's `->`, are annotations
-  lanky evaluates, and lanky's
-  [Known limits](https://github.com/xywei/lanky#known-limits) apply to them:
-  an operation that answers from a term object rather than through its
-  overloads can make the statement say something other than what was
-  written. Read the ledger's `STATEMENT` column.
+  loopty traces a kernel's body itself and checks that trace, the
+  `trace-faithful` fact. A theorem, and the claim after a kernel's `->`, are
+  annotations lanky reads. lanky 0.2.0 checks a theorem's reading at drawn
+  values, the row `the term computes what the annotations compute` under it,
+  and its [Known limits](https://github.com/xywei/lanky#known-limits) say what
+  that check can miss. A postcondition has no such row: read its `STATEMENT`
+  column in the ledger.
 
 The Partial and Not yet lists under Status have the rest, and the
 [open issues](https://github.com/xywei/loopty/issues) have every one.
@@ -878,7 +961,7 @@ loopty runs on Python 3.12 and 3.13: the islpy it is held to has no wheels for
 3.14. CI, and every run this README reports, is on Linux. In a uv project,
 `uv add loopty`, and the same for the extra below. The install pulls in:
 
-- [lanky](https://github.com/xywei/lanky) 0.1.0 or later, the proof host:
+- [lanky](https://github.com/xywei/lanky) 0.2.0 or later, the proof host:
   `lanky check` prints the ledger, and loopty plugs into it;
 - [loopy](https://github.com/inducer/loopy) 2025.2, which generates the code.
   loopty builds on loopy's internals, so a release of loopty is held to the