ulpwise 0.2.0__tar.gz → 0.3.0__tar.gz

{ulpwise-0.2.0 → ulpwise-0.3.0}/.github/workflows/release.yml

@@ -2,7 +2,8 @@
 # uploads them to PyPI through trusted publishing (no API token stored anywhere):
 # the PyPI project "ulpwise" must list this repository, this workflow file name and the
 # "pypi" environment as its publisher. A manual run only builds and checks the wheels,
-# unless its "publish" input is set, in which case it also uploads and tags the commit.
+# unless its "publish" input is set, in which case it also uploads, tags the commit and
+# creates the GitHub release with the CHANGELOG section as notes and the wheels attached.
 name: release
 
 on:
@@ -119,3 +120,20 @@ jobs:
         run: |
           git tag "v${{ steps.version.outputs.version }}"
           git push origin "v${{ steps.version.outputs.version }}"
+      - name: GitHub release with the CHANGELOG section as notes and the wheels attached
+        env:
+          GH_TOKEN: ${{ github.token }}
+          VERSION: ${{ steps.version.outputs.version }}
+        run: |
+          python3 - > notes.md <<'EOF'
+          import os, re
+          version = os.environ["VERSION"]
+          text = open("CHANGELOG.md", encoding="utf-8").read()
+          m = re.search(r"^## " + re.escape(version) + r"\b.*?\n(.*?)(?=^## |\Z)", text, re.M | re.S)
+          print(m.group(1).strip() if m else f"ulpwise {version}, see CHANGELOG.md")
+          EOF
+          if gh release view "v$VERSION" > /dev/null 2>&1; then
+            gh release upload "v$VERSION" dist/* --clobber
+          else
+            gh release create "v$VERSION" dist/* --title "ulpwise $VERSION" --notes-file notes.md
+          fi

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

@@ -1,5 +1,36 @@
 # Changelog
 
+## 0.3.0 (2026-09-26)
+
+- `ulpwise scan`: static scan of a repository (a directory, a GitHub URL or `owner/repo`, cloned
+  with depth 1) for the floating point patterns behind the corpus bugs. Twelve rules with severity,
+  reason, replacement and upstream example: `exp-of-square`, `sin-of-pi-times`, `softplus-by-hand`,
+  `logsumexp-by-hand`, `hypot-by-hand`, `sqrt-of-difference`, `one-minus-cos`, `log1p-by-hand`,
+  `expm1-by-hand`, `atan-of-quotient`, `small-angle-division`, `acos-for-angle`. Findings carry
+  file, line, function and the source line; the report ends with the functions that do the most
+  elementary math. `--report` writes Markdown, `--rules` filters, `--fail-on` gates CI,
+  `--include-tests` widens the walk. On kornia main the four `small-angle-division` and
+  `one-minus-cos` lines are the ones kornia #4897 fixes.
+- `ulpwise scan --run`: imports the math-heavy module level functions and calls them on the same
+  grid in float32 and float64, reporting the largest error in ulps of the largest output and the
+  worst elementwise ulp distance with its input. Static methods run, instance methods and other
+  skips carry their reason. `--run-limit` bounds it, `--run-installed` imports the installed package
+  instead of the scanned tree.
+- `ulp_distance`, `ulp_distances`, `ordered`, `max_ulp` and `assert_max_ulp` take `f16` and
+  `bf16`, and `flatten` reads the dtype off float16 and bfloat16 numpy arrays and torch tensors.
+  Inputs that are not representable are rounded to nearest even first, so a bfloat16 tensor can be
+  measured against a float64 reference; without an explicit dtype the less precise of the two
+  inputs decides. Cross-checked against the numpy int16 view for float16 and the torch view for
+  bfloat16.
+- `special("f16")` and `special("bf16")`: the same 29 named edge values as f32 and f64, so
+  `edge_values`, the `edge_f16` and `edge_bf16` pytest fixtures and `ulpwise special f16` work.
+  Every value satisfies the same checks as the f32 and f64 tables, run through numpy for float16
+  and torch for bfloat16.
+- `ulpwise corpus`: runs the regression corpus against the installed packages without pytest and
+  prints one line per case, present, fixed or skipped, with the installed version and the upstream
+  reference. `--repo` filters by repository or case id, `--fail-if-present` makes a present bug exit 1.
+  Any exception from a repro counts as present, like the pytest run: several corpus bugs are crashes.
+
 ## 0.2.0 (2026-09-26)
 
 - `ulpwise survey` (`ulpwise.survey`): accuracy survey of 61 elementary and special functions of

{ulpwise-0.2.0 → ulpwise-0.3.0}/Cargo.lock

@@ -120,7 +120,7 @@ checksum = "adb6935a6f5c20170eeceb1a3835a49e12e19d792f6dd344ccc76a985ca5a6ca"
 
 [[package]]
 name = "ulpwise"
-version = "0.2.0"
+version = "0.3.0"
 dependencies = [
  "pyo3",
 ]

{ulpwise-0.2.0 → ulpwise-0.3.0}/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "ulpwise"
-version = "0.2.0"
+version = "0.3.0"
 edition = "2021"
 rust-version = "1.86"
 license = "MIT OR Apache-2.0"

{ulpwise-0.2.0 → ulpwise-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ulpwise
-Version: 0.2.0
+Version: 0.3.0
 Classifier: Development Status :: 3 - Alpha
 Classifier: Framework :: Pytest
 Classifier: Intended Audience :: Developers
@@ -30,7 +30,7 @@ Project-URL: Repository, https://github.com/Nicholas022400701/ulpwise
 
 Numerical conformance testing for ML code. A Rust core with a Python API and a pytest plugin.
 
-`ulpwise` answers three questions that come up every time a numerical test goes red on one
+`ulpwise` answers five questions that come up every time a numerical test goes red on one
 platform and green on another:
 
 1. **Which inputs break first?** Named edge values computed from the float format (the largest
@@ -47,6 +47,10 @@ platform and green on another:
    `ulpwise survey` measures 61 elementary and special functions of torch, numpy, scipy and jax in
    ulps against a 200 bit mpmath reference and, for torch, checks every error against the tolerance
    of torch's own `OpInfo` reference test, default and per op override.
+5. **Where should I read first in a repository I do not know?** `ulpwise scan` parses every Python
+   file and reports the expressions behind the bugs in the corpus (`exp(x * x)`, `sin(pi * x)`,
+   `1 - cos(x)`, `sqrt(a * a + b * b)`, `log(1 + exp(x))`, divisions by an unguarded angle, ...)
+   with file, line and function, then lists the functions with the most elementary math.
 
 ## Why this exists
 
@@ -109,12 +113,15 @@ The Rust crate is usable on its own (`cargo add --git https://github.com/Nichola
 ```python
 import ulpwise
 
-# ulp distances, dtype aware: a float32 tensor is measured in float32 ulps.
+# ulp distances, dtype aware: a float32 tensor is measured in float32 ulps, a bfloat16 tensor
+# against a float64 reference in bfloat16 ulps. f64, f32, f16 and bf16.
 ulpwise.ulp_distance(0.9235056042671204, 0.9235056638717651, "f32")   # 1
+ulpwise.ulp_distance(1.0, 1.001, "bf16")                              # 0, both round to 1.0
 ulpwise.assert_max_ulp(torch_out, reference, max_ulp_=2)               # floats, lists, numpy, torch
 
-# the 29 named edge values of a dtype
+# the 29 named edge values of a dtype, f64 f32 f16 bf16
 dict(ulpwise.special("f32"))["square_underflows_to_zero"]              # 2.6469779601696886e-23, the largest x with x * x == 0
+dict(ulpwise.special("bf16"))["square_overflows"]                      # 1.8446744073709552e+19, 2 ** 64
 
 # exact placement of a result relative to its rounding midpoint
 ulpwise.midpoint("sqrt", 0.8528626561164856, "f32")   # (0.9235056042671204, 0.000377, True, False)
@@ -133,8 +140,8 @@ ulpwise.sqrt_cr(0.8528626561164856, "f32")            # 0.9235056042671204
 
 ### pytest plugin
 
-Installed automatically. A test that takes `edge_f32` or `edge_f64` runs once per named edge
-value, and `assert_max_ulp` is available as a fixture:
+Installed automatically. A test that takes `edge_f64`, `edge_f32`, `edge_f16` or `edge_bf16` runs
+once per named edge value, and `assert_max_ulp` is available as a fixture:
 
 ```python
 def test_my_kernel_survives_the_edges(edge_f32, assert_max_ulp):
@@ -151,6 +158,9 @@ project grew out of, each with a runnable repro, the buggy behaviour quoted from
 request, and the check that tells the two apart. `pytest tests/test_corpus.py` runs every case
 whose packages are installed; a case is an expected failure while the installed release is not
 known to contain the fix, so the run tells you which bugs are present in your environment.
+`ulpwise corpus` does the same without pytest, one line per case with the installed version and
+`present`, `fixed` or `skipped`; `ulpwise corpus --repo pytorch --fail-if-present` is the CI gate
+form.
 
 | case | kind | merged |
 |---|---|---|
@@ -181,6 +191,69 @@ expected failures until a release contains the fix (`fixed_in_release` in `cases
 in a temporary directory and needs no weights; two more ultralytics fixes (#26240, #26246) are not in
 the corpus yet because their repros need model weights or the COCO evaluator.
 
+## Repository scan
+
+```sh
+ulpwise scan kornia/kornia --report kornia.md        # clone with depth 1, write a Markdown report
+ulpwise scan . --fail-on high                        # CI gate: exit 1 on a high severity finding
+ulpwise scan path/to/repo --rules one-minus-cos,small-angle-division --top 40
+```
+
+The scan is static and needs nothing installed: it parses each file with `ast`, walks every
+function and matches twelve patterns, each with a severity, the reason it loses digits or
+overflows, the usual replacement and, where one exists, the upstream bug it comes from.
+
+| rule | severity | pattern |
+|---|---|---|
+| `exp-of-square` | high | `exp(x * x)`, `exp(x ** 2)`, `(-x.pow(2)).exp()`: the rounding error of the square is multiplied by `x * x / 2` ulps (pytorch #198664) |
+| `sin-of-pi-times` | high | `sin(pi * x)`, `cos(pi * x)`: the product is rounded before the argument reduction (pytorch #198663) |
+| `softplus-by-hand` | high | `log(1 + exp(x))` |
+| `logsumexp-by-hand` | high | `log(exp(a) + exp(b))`, `log(sum(exp(x)))` |
+| `hypot-by-hand` | high | `sqrt(a * a + b * b)` |
+| `sqrt-of-difference` | medium | `sqrt(a - b)` |
+| `one-minus-cos` | medium | `1 - cos(x)` (kornia #4897) |
+| `log1p-by-hand`, `expm1-by-hand` | medium | `log(1 + x)`, `exp(x) - 1` |
+| `atan-of-quotient` | medium | `atan(y / x)` |
+| `small-angle-division` | medium | `/ theta`, `/ theta ** 2`, `/ sin(theta)` in a function that takes `sin` or `cos` of `theta` and has no `where`, `clamp`, `eps` or series in sight (kornia #4838, #4897) |
+| `acos-for-angle` | info | `acos`, `asin` used to recover an angle |
+
+On kornia `main` at `e05b0ee` the scan takes 4 s for 506 files and reports 35 findings. The
+`one-minus-cos` and `small-angle-division` findings are the four lines of `So3.right_jacobian` and
+`So3.left_jacobian` that kornia #4897 fixes, `So3.log` (kornia #4838) is under `acos-for-angle`,
+and `Se3.exp` (also #4897) is under `one-minus-cos`. The scan puts `ellipse_to_laf` (kornia #4768)
+on the list too, for a `sqrt` of a difference; the bug there was a different one, so that entry is
+what the scan is: a reading list, not a verdict.
+
+`--run` adds the dynamic half. The module level functions with the most elementary math are
+imported and called with the same 91 point grid (both signs of `1e-8` to `1e3`, and zero) for every
+required argument, in float32 and in float64, torch first and numpy second, and the float32 result
+is measured against the float64 one. Two numbers per function: `at scale`, the largest absolute
+error in ulps of the largest output, and `elementwise`, the worst per element ulp distance with
+the input where it happens. Read both. A rotation matrix has entries that should be zero, and
+there the elementwise count compares float32 rounding noise with float64 rounding noise and reaches
+`1e9` while the matrix is fine to one ulp at scale. A function whose output spans forty orders of
+magnitude, a Bessel function, has a meaningless `at scale` number and a meaningful elementwise one.
+A small angle formula without a guard, `(1 - cos(theta)) / theta ** 2`, shows `9e6` in both
+columns. Static methods run; instance methods, functions that need other arguments, fail to import
+or return something that is not a float array are counted with the reason and skipped, never
+guessed at. This imports and runs the repository's code, from the scanned tree, or from the
+package installed in the environment with `--run-installed` when the tree has unbuilt extensions.
+
+```sh
+ulpwise scan kornia/kornia --run --run-limit 200 --report kornia.md
+ulpwise scan pytorch/vision --run --run-installed --run-limit 150
+```
+
+On kornia main 9 of the 200 busiest functions run as is, the rest are instance methods or want
+shaped inputs. `adjust_log` is on both lists: the static scan flags its `(1 + image).log2()` as
+`log1p-by-hand`, and the run shows `8.7e8` elementwise ulps at `x = 5.6e-8` next to `0.7` ulps at
+scale, which is the right reading for a function defined on images in `[0, 1]`.
+
+In ML repositories most `high` findings are learning rate schedules (`cos(pi * progress)` with
+`progress` in `[0, 1]`) and pixel distances (`sqrt(dx * dx + dy * dy)` on coordinates below
+`1e4`), where the argument is bounded and the pattern is harmless. The scan cannot know the bound;
+the reading list is where that judgement happens.
+
 ## Accuracy survey
 
 ```sh
@@ -198,14 +271,18 @@ finite mismatches and the worst input. For torch it also reports how many inputs
 kernel and the scalar tail disagree on, and how many inputs would fail torch's reference test under
 the dtype default tolerance and under the op's `OpInfo` override, read from `op_db`.
 
-[`studies/accuracy-survey-2026-09`](studies/accuracy-survey-2026-09/README.md) is the first run
+[`studies/accuracy-survey-2026-09`](https://github.com/Nicholas022400701/ulpwise/blob/main/studies/accuracy-survey-2026-09/README.md) is the first run
 (torch 2.14.0+cpu, numpy 2.2.6, scipy 1.18.1, jax 0.11.2, Linux x86_64 AVX512). The short version:
 
 - torch's `bessel_j0/j1/y0/y1` and `airy_ai` in float64 are off by 2.6e9 to 3.9e12 ulps and the
-  `precisionOverride({torch.float64: 1e-05})` on their tests hides every failing input.
+  `precisionOverride({torch.float64: 1e-05})` on their tests hides every failing input
+  (pytorch #198583).
 - torch's `polygamma(1, x)` in float64 keeps about 9 digits (4.0e6 ulps, 46 percent of inputs
   beyond 10 ulps) and passes the default float64 tolerance, which at `rtol = atol = 1e-7` tolerates
-  about 4.5e8 ulps.
+  about 4.5e8 ulps; in float32 it loses every digit for large negative `x` (pytorch #198663).
+- torch's `erfcx` for negative `x` is off by up to `x*x/2` ulps, 44 in float32 at `x = -8.44` and
+  157 in float64 at `x = -23.25`, and scipy's float64 `erfcx` returns the same wrong values
+  (pytorch #198664).
 - for 12 of 61 torch functions the AVX512 kernel and the scalar tail return different floats for
   the same input, up to 246 of 619 inputs for `mish`.
 - jax on CPU flushes subnormals to zero, its float64 `erfinv` loses 5 digits near the ends of the
@@ -226,9 +303,11 @@ cross-checks both against `fractions.Fraction` and `decimal.Decimal` at 80 digit
 
 ## Roadmap
 
+- `ulpwise scan --run` for methods and functions with tensor shape requirements, by reading the
+  docstring and the checks for the shapes, and an mpmath reference for the scalar functions.
 - Mutation scoring for numerical tests: single token mutants of the code under test (`abs`, a
   dropped `sqrt`, `/ 4` for `/ 16`) run against the test suite, reporting which survive.
-- `float16` and `bfloat16` ulps and edge values.
+- `float16` and `bfloat16` `spacing`, `next_up`, knife edges and exact oracles (ulp distances and edge values are done).
 - Exact references for transcendental functions in Rust (correctly rounded `exp`, `log`, ...) so
   the `f64` knife-edge scans do not need mpmath.
 - Survey backends for CUDA and MPS, and `float16` / `bfloat16` rows.
@@ -246,8 +325,8 @@ those pull requests carries the same disclosure.
 
 Licensed under either of
 
-- the MIT license ([LICENSE-MIT](LICENSE-MIT)), or
-- the Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE)),
+- the MIT license ([LICENSE-MIT](https://github.com/Nicholas022400701/ulpwise/blob/main/LICENSE-MIT)), or
+- the Apache License, Version 2.0 ([LICENSE-APACHE](https://github.com/Nicholas022400701/ulpwise/blob/main/LICENSE-APACHE)),
 
 at your option. "At your option" means that whoever uses or redistributes this code picks
 whichever of the two licenses they want to comply with. Nobody has to ask anyone. Unless you say

{ulpwise-0.2.0 → ulpwise-0.3.0}/README.md

@@ -2,7 +2,7 @@
 
 Numerical conformance testing for ML code. A Rust core with a Python API and a pytest plugin.
 
-`ulpwise` answers three questions that come up every time a numerical test goes red on one
+`ulpwise` answers five questions that come up every time a numerical test goes red on one
 platform and green on another:
 
 1. **Which inputs break first?** Named edge values computed from the float format (the largest
@@ -19,6 +19,10 @@ platform and green on another:
    `ulpwise survey` measures 61 elementary and special functions of torch, numpy, scipy and jax in
    ulps against a 200 bit mpmath reference and, for torch, checks every error against the tolerance
    of torch's own `OpInfo` reference test, default and per op override.
+5. **Where should I read first in a repository I do not know?** `ulpwise scan` parses every Python
+   file and reports the expressions behind the bugs in the corpus (`exp(x * x)`, `sin(pi * x)`,
+   `1 - cos(x)`, `sqrt(a * a + b * b)`, `log(1 + exp(x))`, divisions by an unguarded angle, ...)
+   with file, line and function, then lists the functions with the most elementary math.
 
 ## Why this exists
 
@@ -81,12 +85,15 @@ The Rust crate is usable on its own (`cargo add --git https://github.com/Nichola
 ```python
 import ulpwise
 
-# ulp distances, dtype aware: a float32 tensor is measured in float32 ulps.
+# ulp distances, dtype aware: a float32 tensor is measured in float32 ulps, a bfloat16 tensor
+# against a float64 reference in bfloat16 ulps. f64, f32, f16 and bf16.
 ulpwise.ulp_distance(0.9235056042671204, 0.9235056638717651, "f32")   # 1
+ulpwise.ulp_distance(1.0, 1.001, "bf16")                              # 0, both round to 1.0
 ulpwise.assert_max_ulp(torch_out, reference, max_ulp_=2)               # floats, lists, numpy, torch
 
-# the 29 named edge values of a dtype
+# the 29 named edge values of a dtype, f64 f32 f16 bf16
 dict(ulpwise.special("f32"))["square_underflows_to_zero"]              # 2.6469779601696886e-23, the largest x with x * x == 0
+dict(ulpwise.special("bf16"))["square_overflows"]                      # 1.8446744073709552e+19, 2 ** 64
 
 # exact placement of a result relative to its rounding midpoint
 ulpwise.midpoint("sqrt", 0.8528626561164856, "f32")   # (0.9235056042671204, 0.000377, True, False)
@@ -105,8 +112,8 @@ ulpwise.sqrt_cr(0.8528626561164856, "f32")            # 0.9235056042671204
 
 ### pytest plugin
 
-Installed automatically. A test that takes `edge_f32` or `edge_f64` runs once per named edge
-value, and `assert_max_ulp` is available as a fixture:
+Installed automatically. A test that takes `edge_f64`, `edge_f32`, `edge_f16` or `edge_bf16` runs
+once per named edge value, and `assert_max_ulp` is available as a fixture:
 
 ```python
 def test_my_kernel_survives_the_edges(edge_f32, assert_max_ulp):
@@ -123,6 +130,9 @@ project grew out of, each with a runnable repro, the buggy behaviour quoted from
 request, and the check that tells the two apart. `pytest tests/test_corpus.py` runs every case
 whose packages are installed; a case is an expected failure while the installed release is not
 known to contain the fix, so the run tells you which bugs are present in your environment.
+`ulpwise corpus` does the same without pytest, one line per case with the installed version and
+`present`, `fixed` or `skipped`; `ulpwise corpus --repo pytorch --fail-if-present` is the CI gate
+form.
 
 | case | kind | merged |
 |---|---|---|
@@ -153,6 +163,69 @@ expected failures until a release contains the fix (`fixed_in_release` in `cases
 in a temporary directory and needs no weights; two more ultralytics fixes (#26240, #26246) are not in
 the corpus yet because their repros need model weights or the COCO evaluator.
 
+## Repository scan
+
+```sh
+ulpwise scan kornia/kornia --report kornia.md        # clone with depth 1, write a Markdown report
+ulpwise scan . --fail-on high                        # CI gate: exit 1 on a high severity finding
+ulpwise scan path/to/repo --rules one-minus-cos,small-angle-division --top 40
+```
+
+The scan is static and needs nothing installed: it parses each file with `ast`, walks every
+function and matches twelve patterns, each with a severity, the reason it loses digits or
+overflows, the usual replacement and, where one exists, the upstream bug it comes from.
+
+| rule | severity | pattern |
+|---|---|---|
+| `exp-of-square` | high | `exp(x * x)`, `exp(x ** 2)`, `(-x.pow(2)).exp()`: the rounding error of the square is multiplied by `x * x / 2` ulps (pytorch #198664) |
+| `sin-of-pi-times` | high | `sin(pi * x)`, `cos(pi * x)`: the product is rounded before the argument reduction (pytorch #198663) |
+| `softplus-by-hand` | high | `log(1 + exp(x))` |
+| `logsumexp-by-hand` | high | `log(exp(a) + exp(b))`, `log(sum(exp(x)))` |
+| `hypot-by-hand` | high | `sqrt(a * a + b * b)` |
+| `sqrt-of-difference` | medium | `sqrt(a - b)` |
+| `one-minus-cos` | medium | `1 - cos(x)` (kornia #4897) |
+| `log1p-by-hand`, `expm1-by-hand` | medium | `log(1 + x)`, `exp(x) - 1` |
+| `atan-of-quotient` | medium | `atan(y / x)` |
+| `small-angle-division` | medium | `/ theta`, `/ theta ** 2`, `/ sin(theta)` in a function that takes `sin` or `cos` of `theta` and has no `where`, `clamp`, `eps` or series in sight (kornia #4838, #4897) |
+| `acos-for-angle` | info | `acos`, `asin` used to recover an angle |
+
+On kornia `main` at `e05b0ee` the scan takes 4 s for 506 files and reports 35 findings. The
+`one-minus-cos` and `small-angle-division` findings are the four lines of `So3.right_jacobian` and
+`So3.left_jacobian` that kornia #4897 fixes, `So3.log` (kornia #4838) is under `acos-for-angle`,
+and `Se3.exp` (also #4897) is under `one-minus-cos`. The scan puts `ellipse_to_laf` (kornia #4768)
+on the list too, for a `sqrt` of a difference; the bug there was a different one, so that entry is
+what the scan is: a reading list, not a verdict.
+
+`--run` adds the dynamic half. The module level functions with the most elementary math are
+imported and called with the same 91 point grid (both signs of `1e-8` to `1e3`, and zero) for every
+required argument, in float32 and in float64, torch first and numpy second, and the float32 result
+is measured against the float64 one. Two numbers per function: `at scale`, the largest absolute
+error in ulps of the largest output, and `elementwise`, the worst per element ulp distance with
+the input where it happens. Read both. A rotation matrix has entries that should be zero, and
+there the elementwise count compares float32 rounding noise with float64 rounding noise and reaches
+`1e9` while the matrix is fine to one ulp at scale. A function whose output spans forty orders of
+magnitude, a Bessel function, has a meaningless `at scale` number and a meaningful elementwise one.
+A small angle formula without a guard, `(1 - cos(theta)) / theta ** 2`, shows `9e6` in both
+columns. Static methods run; instance methods, functions that need other arguments, fail to import
+or return something that is not a float array are counted with the reason and skipped, never
+guessed at. This imports and runs the repository's code, from the scanned tree, or from the
+package installed in the environment with `--run-installed` when the tree has unbuilt extensions.
+
+```sh
+ulpwise scan kornia/kornia --run --run-limit 200 --report kornia.md
+ulpwise scan pytorch/vision --run --run-installed --run-limit 150
+```
+
+On kornia main 9 of the 200 busiest functions run as is, the rest are instance methods or want
+shaped inputs. `adjust_log` is on both lists: the static scan flags its `(1 + image).log2()` as
+`log1p-by-hand`, and the run shows `8.7e8` elementwise ulps at `x = 5.6e-8` next to `0.7` ulps at
+scale, which is the right reading for a function defined on images in `[0, 1]`.
+
+In ML repositories most `high` findings are learning rate schedules (`cos(pi * progress)` with
+`progress` in `[0, 1]`) and pixel distances (`sqrt(dx * dx + dy * dy)` on coordinates below
+`1e4`), where the argument is bounded and the pattern is harmless. The scan cannot know the bound;
+the reading list is where that judgement happens.
+
 ## Accuracy survey
 
 ```sh
@@ -170,14 +243,18 @@ finite mismatches and the worst input. For torch it also reports how many inputs
 kernel and the scalar tail disagree on, and how many inputs would fail torch's reference test under
 the dtype default tolerance and under the op's `OpInfo` override, read from `op_db`.
 
-[`studies/accuracy-survey-2026-09`](studies/accuracy-survey-2026-09/README.md) is the first run
+[`studies/accuracy-survey-2026-09`](https://github.com/Nicholas022400701/ulpwise/blob/main/studies/accuracy-survey-2026-09/README.md) is the first run
 (torch 2.14.0+cpu, numpy 2.2.6, scipy 1.18.1, jax 0.11.2, Linux x86_64 AVX512). The short version:
 
 - torch's `bessel_j0/j1/y0/y1` and `airy_ai` in float64 are off by 2.6e9 to 3.9e12 ulps and the
-  `precisionOverride({torch.float64: 1e-05})` on their tests hides every failing input.
+  `precisionOverride({torch.float64: 1e-05})` on their tests hides every failing input
+  (pytorch #198583).
 - torch's `polygamma(1, x)` in float64 keeps about 9 digits (4.0e6 ulps, 46 percent of inputs
   beyond 10 ulps) and passes the default float64 tolerance, which at `rtol = atol = 1e-7` tolerates
-  about 4.5e8 ulps.
+  about 4.5e8 ulps; in float32 it loses every digit for large negative `x` (pytorch #198663).
+- torch's `erfcx` for negative `x` is off by up to `x*x/2` ulps, 44 in float32 at `x = -8.44` and
+  157 in float64 at `x = -23.25`, and scipy's float64 `erfcx` returns the same wrong values
+  (pytorch #198664).
 - for 12 of 61 torch functions the AVX512 kernel and the scalar tail return different floats for
   the same input, up to 246 of 619 inputs for `mish`.
 - jax on CPU flushes subnormals to zero, its float64 `erfinv` loses 5 digits near the ends of the
@@ -198,9 +275,11 @@ cross-checks both against `fractions.Fraction` and `decimal.Decimal` at 80 digit
 
 ## Roadmap
 
+- `ulpwise scan --run` for methods and functions with tensor shape requirements, by reading the
+  docstring and the checks for the shapes, and an mpmath reference for the scalar functions.
 - Mutation scoring for numerical tests: single token mutants of the code under test (`abs`, a
   dropped `sqrt`, `/ 4` for `/ 16`) run against the test suite, reporting which survive.
-- `float16` and `bfloat16` ulps and edge values.
+- `float16` and `bfloat16` `spacing`, `next_up`, knife edges and exact oracles (ulp distances and edge values are done).
 - Exact references for transcendental functions in Rust (correctly rounded `exp`, `log`, ...) so
   the `f64` knife-edge scans do not need mpmath.
 - Survey backends for CUDA and MPS, and `float16` / `bfloat16` rows.
@@ -218,8 +297,8 @@ those pull requests carries the same disclosure.
 
 Licensed under either of
 
-- the MIT license ([LICENSE-MIT](LICENSE-MIT)), or
-- the Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE)),
+- the MIT license ([LICENSE-MIT](https://github.com/Nicholas022400701/ulpwise/blob/main/LICENSE-MIT)), or
+- the Apache License, Version 2.0 ([LICENSE-APACHE](https://github.com/Nicholas022400701/ulpwise/blob/main/LICENSE-APACHE)),
 
 at your option. "At your option" means that whoever uses or redistributes this code picks
 whichever of the two licenses they want to comply with. Nobody has to ask anyone. Unless you say

{ulpwise-0.2.0 → ulpwise-0.3.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "maturin"
 
 [project]
 name = "ulpwise"
-version = "0.2.0"
+version = "0.3.0"
 description = "Numerical conformance testing for ML code: float edge values, exact rounding oracles, knife-edge finders and a pytest plugin"
 readme = "README.md"
 license = { text = "MIT OR Apache-2.0" }