ulpwise 0.1.2__tar.gz → 0.2.0__tar.gz

ulpwise-0.2.0/CHANGELOG.md

@@ -0,0 +1,49 @@
+# Changelog
+
+## 0.2.0 (2026-09-26)
+
+- `ulpwise survey` (`ulpwise.survey`): accuracy survey of 61 elementary and special functions of
+  torch, numpy, scipy and jax against a 200 bit mpmath reference, in ulps of the dtype, with the
+  worst input per row. For torch it also counts inputs where the vectorized kernel and the scalar
+  tail disagree and inputs that would fail the `OpInfo` reference test tolerance, default and per op
+  override, read from `op_db`. Writes `results.csv` and `results.md`. Optional extra
+  `ulpwise[survey]` pulls in mpmath.
+- `studies/accuracy-survey-2026-09`: the first run and its reading notes.
+- Corpus: `max_ulp` check type, and five open cases with the complete patch attached to the issue:
+  pytorch #198448 (`torch.sqrt` float64 rounding), pytorch #198583 (Bessel and Airy `p1evl` leading
+  1), kornia #4838 and #4897 (small angle series), torchvision #9676 (rotated box clamp). Open cases
+  carry `issue`, `pr: null` and `fixed_in_release: null` and stay expected failures until a release
+  contains the fix.
+- Corpus: three more open cases, pytorch #198663 (`polygamma(1, x)`: float64 series truncation and
+  float32 reflection argument) and pytorch #198664 (`erfcx` negative branch, `exp` at the rounded
+  square), both with the complete patch attached to the issue.
+- Corpus: kornia #4768, `ellipse_to_laf` described the wrong ellipse whenever `b != 0`.
+- Corpus: ultralytics #26330, OBB datasets with plain box labels are rejected at load time; the repro
+  writes a one-image dataset to a temporary directory, so it needs ultralytics but no weights.
+
+## 0.1.2 (2026-09-24)
+
+- `ulpwise` console script, so `uvx ulpwise midpoint sqrt 0.85`, `pipx run ulpwise ...` and a plain
+  `ulpwise ...` inside a virtualenv work without `python -m`.
+
+## 0.1.1 (2026-09-24)
+
+No code changes. The AI disclosure in the README was shortened and the package was republished
+from a repository with a fresh history.
+
+## 0.1.0 (2026-09-24)
+
+First release.
+
+- Rust core: ordered float views and ulp distances (`ulp`), named edge values computed from the
+  format (`edge`), exact rounding oracles for `sqrt`, reciprocal and division with correctly rounded
+  results that do not depend on the platform libm, f64 referenced midpoint reports for 15 more
+  `f32` functions (`exact`), and knife-edge scans (`knife`).
+- Python package built with maturin: `ulp_distance`, `assert_max_ulp` and `max_ulp` for floats,
+  lists, numpy arrays and torch tensors, `special`, `neighbours`, `binade_edges`, `all_floats`,
+  `midpoint`, `knife_edges`, `sqrt_cr`, a CLI (`python -m ulpwise`) and a pytest plugin
+  (`edge_f32` / `edge_f64` parametrization, `assert_max_ulp` fixture).
+- Regression corpus of 11 upstream bugs with runnable repros (kornia, pytorch, pytorch/rl, timm,
+  peft), run by `tests/test_corpus.py` against whatever is installed.
+- `examples/torch_sqrt_conformance.py`: measures how often a platform's `torch.sqrt` and
+  `numpy.sqrt` disagree with correct rounding at knife-edge inputs.

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

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

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

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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ulpwise
-Version: 0.1.2
+Version: 0.2.0
 Classifier: Development Status :: 3 - Alpha
 Classifier: Framework :: Pytest
 Classifier: Intended Audience :: Developers
@@ -9,8 +9,11 @@ Classifier: Programming Language :: Python :: 3
 Classifier: Programming Language :: Rust
 Classifier: Topic :: Software Development :: Testing
 Classifier: Topic :: Scientific/Engineering :: Mathematics
+Requires-Dist: numpy ; extra == 'survey'
+Requires-Dist: mpmath>=1.3 ; extra == 'survey'
 Requires-Dist: pytest>=7 ; extra == 'test'
 Requires-Dist: numpy ; extra == 'test'
+Provides-Extra: survey
 Provides-Extra: test
 License-File: LICENSE-APACHE
 License-File: LICENSE-MIT
@@ -40,6 +43,10 @@ platform and green on another:
 3. **Where do two implementations disagree?** Knife-edge scans: the inputs whose exact result sits
    within `tol` ulp of a rounding midpoint, so that two implementations that differ by one ulp
    return different floats. 8.4 million `f32` inputs are scanned in about 0.3 s.
+4. **How accurate are the functions I call, and would the library's own tests notice?**
+   `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.
 
 ## Why this exists
 
@@ -149,6 +156,7 @@ known to contain the fix, so the run tells you which bugs are present in your en
 |---|---|---|
 | kornia #4683 second derivative sign in `spatial_gradient(order=2)` | sign | 2026-09-22 |
 | kornia #4767 mixed second order kernel scale, wrong `hessian_response` determinant | scale | 2026-09-23 |
+| kornia #4768 `ellipse_to_laf` under-tilted every ellipse with `b != 0` | geometry | 2026-09-24 |
 | pytorch #198006 `Multinomial.entropy()` evaluated in the default dtype | dtype | 2026-09-23 |
 | pytorch/rl #4443 `arange(0, 1, 1/n)` gives `n + 1` positions for 140 values of `n` below 2000 | rounding | 2026-09-20 |
 | pytorch/rl #4444 `min_value or -inf` drops `min_value=0` | falsy zero | 2026-09-20 |
@@ -158,9 +166,52 @@ known to contain the fix, so the run tells you which bugs are present in your en
 | timm #2791 AdaMuon conv LR scale computed from the wrong dims | scale | 2026-09-18 |
 | timm #2792 Kron `__setstate__` shadowed | crash | 2026-09-18 |
 | peft #3777 pointwise Conv3d took the conv2d 1x1 shortcut | shape | 2026-09-21 |
+| ultralytics #26330 OBB train and val on plain box labels crashed in the validator or the loss instead of at load time | crash | 2026-09-25 |
+| pytorch #198448 `torch.sqrt` float64 not correctly rounded at 27 of 64 knife edges | rounding | open |
+| pytorch #198583 `bessel_j0/j1/y0/y1`, `airy_ai` float64 lose up to 12 digits (`p1evl` leading 1) | digits | open |
+| kornia #4838 `axis_angle_to_rotation_matrix` drops the `theta^2` terms below 1e-3 rad | series | open |
+| kornia #4897 `So3.log`, the `So3` Jacobians and `Se3.exp/log` lose all digits for small angles | series | open |
+| torchvision #9676 `clamp_bounding_boxes` collapses slightly tilted rotated boxes to a point | geometry | open |
+| pytorch #198663 `polygamma(1, x)` float64 keeps 9 digits (series stops at `1/42`), float32 loses all for large negative `x` | truncation, rounding | open |
+| pytorch #198664 `erfcx` off by `x*x/2` ulps for negative `x` (`exp` at the rounded square) | rounding | open |
+
+Cases marked `open` have an issue with the complete patch attached and no merged fix yet; they are
+expected failures until a release contains the fix (`fixed_in_release` in `cases.json`), and the
+`max_ulp` check type measures the digits directly. The ultralytics case builds its one-image dataset
+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.
+
+## Accuracy survey
 
-Two ultralytics fixes (#26240, #26246) are not in the corpus yet because their repros need model
-weights and a dataset layout; they will come with fixtures.
+```sh
+pip install 'ulpwise[survey]' torch scipy jax      # mpmath is the reference, the rest are backends
+ulpwise survey --out survey                        # results.csv and results.md, about 3 minutes
+ulpwise survey --functions bessel_j0,polygamma_1 --backends torch,scipy --dtypes f64 --points 2000
+```
+
+For every function in `ulpwise.survey.REGISTRY` (exp, log, trig and hyperbolic functions, erf and
+friends, gamma family, torch.special Bessel and Airy functions, the activation functions), every
+dtype and every installed backend, the survey evaluates a log spaced grid over the function's domain
+plus the named edge values of the dtype, computes the exact value with mpmath at the rounded input,
+and reports max, p99 and median error in ulps, the fraction of inputs beyond 1 and 10 ulps, non
+finite mismatches and the worst input. For torch it also reports how many inputs the vectorized
+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
+(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.
+- 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.
+- 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
+  interval and its float64 `log_ndtr` loses 3 digits between `x = 5.4` and 8.
+- scipy's float64 `lgamma` does not handle the zeros at 1 and 2, and its Bessel functions lose the
+  phase at large `x`.
 
 ## How the exact oracle works
 
@@ -178,8 +229,9 @@ cross-checks both against `fractions.Fraction` and `decimal.Decimal` at 80 digit
 - 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.
-- Exact references for transcendental functions (correctly rounded `exp`, `log`, ...) so the `f64`
-  ones can be scanned too.
+- 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.
 - Zero copy paths for numpy arrays and torch tensors.
 - More corpus entries, with fixtures for the cases that need data.
 

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

@@ -15,6 +15,10 @@ platform and green on another:
 3. **Where do two implementations disagree?** Knife-edge scans: the inputs whose exact result sits
    within `tol` ulp of a rounding midpoint, so that two implementations that differ by one ulp
    return different floats. 8.4 million `f32` inputs are scanned in about 0.3 s.
+4. **How accurate are the functions I call, and would the library's own tests notice?**
+   `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.
 
 ## Why this exists
 
@@ -124,6 +128,7 @@ known to contain the fix, so the run tells you which bugs are present in your en
 |---|---|---|
 | kornia #4683 second derivative sign in `spatial_gradient(order=2)` | sign | 2026-09-22 |
 | kornia #4767 mixed second order kernel scale, wrong `hessian_response` determinant | scale | 2026-09-23 |
+| kornia #4768 `ellipse_to_laf` under-tilted every ellipse with `b != 0` | geometry | 2026-09-24 |
 | pytorch #198006 `Multinomial.entropy()` evaluated in the default dtype | dtype | 2026-09-23 |
 | pytorch/rl #4443 `arange(0, 1, 1/n)` gives `n + 1` positions for 140 values of `n` below 2000 | rounding | 2026-09-20 |
 | pytorch/rl #4444 `min_value or -inf` drops `min_value=0` | falsy zero | 2026-09-20 |
@@ -133,9 +138,52 @@ known to contain the fix, so the run tells you which bugs are present in your en
 | timm #2791 AdaMuon conv LR scale computed from the wrong dims | scale | 2026-09-18 |
 | timm #2792 Kron `__setstate__` shadowed | crash | 2026-09-18 |
 | peft #3777 pointwise Conv3d took the conv2d 1x1 shortcut | shape | 2026-09-21 |
+| ultralytics #26330 OBB train and val on plain box labels crashed in the validator or the loss instead of at load time | crash | 2026-09-25 |
+| pytorch #198448 `torch.sqrt` float64 not correctly rounded at 27 of 64 knife edges | rounding | open |
+| pytorch #198583 `bessel_j0/j1/y0/y1`, `airy_ai` float64 lose up to 12 digits (`p1evl` leading 1) | digits | open |
+| kornia #4838 `axis_angle_to_rotation_matrix` drops the `theta^2` terms below 1e-3 rad | series | open |
+| kornia #4897 `So3.log`, the `So3` Jacobians and `Se3.exp/log` lose all digits for small angles | series | open |
+| torchvision #9676 `clamp_bounding_boxes` collapses slightly tilted rotated boxes to a point | geometry | open |
+| pytorch #198663 `polygamma(1, x)` float64 keeps 9 digits (series stops at `1/42`), float32 loses all for large negative `x` | truncation, rounding | open |
+| pytorch #198664 `erfcx` off by `x*x/2` ulps for negative `x` (`exp` at the rounded square) | rounding | open |
+
+Cases marked `open` have an issue with the complete patch attached and no merged fix yet; they are
+expected failures until a release contains the fix (`fixed_in_release` in `cases.json`), and the
+`max_ulp` check type measures the digits directly. The ultralytics case builds its one-image dataset
+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.
+
+## Accuracy survey
 
-Two ultralytics fixes (#26240, #26246) are not in the corpus yet because their repros need model
-weights and a dataset layout; they will come with fixtures.
+```sh
+pip install 'ulpwise[survey]' torch scipy jax      # mpmath is the reference, the rest are backends
+ulpwise survey --out survey                        # results.csv and results.md, about 3 minutes
+ulpwise survey --functions bessel_j0,polygamma_1 --backends torch,scipy --dtypes f64 --points 2000
+```
+
+For every function in `ulpwise.survey.REGISTRY` (exp, log, trig and hyperbolic functions, erf and
+friends, gamma family, torch.special Bessel and Airy functions, the activation functions), every
+dtype and every installed backend, the survey evaluates a log spaced grid over the function's domain
+plus the named edge values of the dtype, computes the exact value with mpmath at the rounded input,
+and reports max, p99 and median error in ulps, the fraction of inputs beyond 1 and 10 ulps, non
+finite mismatches and the worst input. For torch it also reports how many inputs the vectorized
+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
+(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.
+- 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.
+- 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
+  interval and its float64 `log_ndtr` loses 3 digits between `x = 5.4` and 8.
+- scipy's float64 `lgamma` does not handle the zeros at 1 and 2, and its Bessel functions lose the
+  phase at large `x`.
 
 ## How the exact oracle works
 
@@ -153,8 +201,9 @@ cross-checks both against `fractions.Fraction` and `decimal.Decimal` at 80 digit
 - 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.
-- Exact references for transcendental functions (correctly rounded `exp`, `log`, ...) so the `f64`
-  ones can be scanned too.
+- 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.
 - Zero copy paths for numpy arrays and torch tensors.
 - More corpus entries, with fixtures for the cases that need data.
 

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

@@ -4,7 +4,7 @@ build-backend = "maturin"
 
 [project]
 name = "ulpwise"
-version = "0.1.2"
+version = "0.2.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" }
@@ -25,6 +25,7 @@ dependencies = []
 
 [project.optional-dependencies]
 test = ["pytest>=7", "numpy"]
+survey = ["numpy", "mpmath>=1.3"]
 
 [project.scripts]
 ulpwise = "ulpwise.__main__:main"

{ulpwise-0.1.2 → ulpwise-0.2.0}/python/ulpwise/__init__.py

@@ -25,7 +25,7 @@ from ._core import (  # noqa: F401
     ulp_distances,
 )
 
-__version__ = "0.1.2"
+__version__ = "0.2.0"
 
 __all__ = [
     "UNARY_OPS",

{ulpwise-0.1.2 → ulpwise-0.2.0}/python/ulpwise/__main__.py

@@ -39,6 +39,13 @@ def main(argv=None):
     u.add_argument("b", type=float)
     u.add_argument("--dtype", default="f64")
 
+    v = sub.add_parser("survey", help="accuracy survey of elementary and special functions against mpmath")
+    v.add_argument("--backends", default="torch,numpy,scipy,jax", help="comma separated: torch numpy scipy jax")
+    v.add_argument("--dtypes", default="f32,f64")
+    v.add_argument("--points", type=int, default=600, help="grid points per function and dtype")
+    v.add_argument("--functions", default=None, help="comma separated subset of function names")
+    v.add_argument("--out", default="survey", help="output directory for results.csv and results.md")
+
     args = parser.parse_args(argv)
     if args.cmd == "knife":
         hits = ulpwise.knife_edges(args.op, args.lo, args.hi, args.tol, args.dtype, args.limit, args.stride)
@@ -62,6 +69,10 @@ def main(argv=None):
             print(f"{name:>26}  {value!r}")
     elif args.cmd == "ulp":
         print(ulpwise.ulp_distance(args.a, args.b, args.dtype))
+    elif args.cmd == "survey":
+        from ulpwise import survey as _survey
+
+        return _survey.main(args)
     return 0
 
 

{ulpwise-0.1.2 → ulpwise-0.2.0}/python/ulpwise/corpus/__init__.py

@@ -67,6 +67,10 @@ def run(case: Dict[str, Any]) -> None:
             ok = math.copysign(1.0, a) == math.copysign(1.0, e) and (a != 0) == (e != 0)
         elif kind == "allclose":
             ok = math.isfinite(a) and abs(a - e) <= check.get("atol", 0.0) + check.get("rtol", 0.0) * abs(e)
+        elif kind == "max_ulp":
+            from ulpwise import ulp_distance  # noqa: PLC0415
+
+            ok = math.isfinite(a) and ulp_distance(a, e, check.get("dtype", "f64")) <= check["max_ulp"]
         else:
             raise ValueError(f"unknown check type {kind!r}")
         if not ok:

{ulpwise-0.1.2 → ulpwise-0.2.0}/python/ulpwise/corpus/cases.json

@@ -1,6 +1,6 @@
 {
  "schema": 1,
- "description": "Regression corpus: numerical and API bugs found by this project's contribution pipeline and merged upstream. Each repro sets `actual` and `expected`; `check` says how to compare. `before_fix` is what the buggy release produced, quoted from the merged pull request.",
+ "description": "Regression corpus: numerical and API bugs found by this project's contribution pipeline. Each repro sets `actual` and `expected`; `check` says how to compare. `before_fix` is what the buggy release produced. Cases with a `pr` are merged upstream; cases with an `issue` and no `pr` are reported upstream with a patch attached and still open, so they are expected failures until the fix lands and `fixed_in_release` is set.",
  "cases": [
   {
    "id": "kornia-4683-second-order-derivative-sign",
@@ -42,6 +42,27 @@
    },
    "before_fix": "[-3.1605, 0.25, -2.1605]"
   },
+  {
+   "id": "kornia-4768-ellipse-to-laf-tilt",
+   "repo": "kornia/kornia",
+   "pr": 4768,
+   "merged_at": "2026-09-24T09:11:00Z",
+   "kind": "geometry",
+   "title": "ellipse_to_laf took the triangular square root of [[a, 0], [b, c]] instead of the symmetric [[a, b], [b, c]], so every ellipse with b != 0 came back under-tilted",
+   "symptom": "The region described by the returned LAF, inverse(A @ A.T), was [[1.0625, 0.25], [0.25, 1]] for the ellipse (a, b, c) = (1, 0.5, 1) and [[2.18, -0.3], [-0.3, 0.5]] for (2, -0.9, 0.5); LAFAffineShapeEstimator inherited the tilt error for every patch whose dominant gradient is not axis-aligned.",
+   "requires": [
+    "torch",
+    "kornia"
+   ],
+   "fixed_in_release": null,
+   "repro": "import torch\nimport kornia.feature as KF\n# Oxford ellipses [x, y, a, b, c]; the LAF's A must satisfy A @ A.T == inverse([[a, b], [b, c]])\nells = torch.tensor([[[0.0, 0.0, 1.0, 0.5, 1.0], [3.0, -2.0, 2.0, -0.9, 0.5]]], dtype=torch.float64)\nA = KF.ellipse_to_laf(ells)[..., :2]\nregion = torch.linalg.inv(A @ A.transpose(-1, -2))[0]\nactual = region.reshape(-1).tolist()\nexpected = [1.0, 0.5, 0.5, 1.0, 2.0, -0.9, -0.9, 0.5]\n",
+   "check": {
+    "type": "allclose",
+    "atol": 1e-12,
+    "rtol": 0.0
+   },
+   "before_fix": "[1.0625, 0.25, 0.25, 1.0, 2.18, -0.3, -0.3, 0.5]"
+  },
   {
    "id": "pytorch-198006-multinomial-entropy-dtype",
    "repo": "pytorch/pytorch",
@@ -224,6 +245,192 @@
     "rtol": 1e-05
    },
    "before_fix": "RuntimeError from the matmul inside get_delta_weight during merge_adapter"
+  },
+  {
+   "id": "pytorch-198448-sqrt-not-correctly-rounded",
+   "repo": "pytorch/pytorch",
+   "pr": null,
+   "issue": 198448,
+   "merged_at": null,
+   "kind": "rounding",
+   "title": "torch.sqrt on CPU is not correctly rounded when the build routes it through MKL VML",
+   "symptom": "At float32 knife edges in [0.5, 1) torch.sqrt returned the float below the correctly rounded result on 7,131 of 16,996 inputs (always down); numpy.sqrt and torch.sqrt in float64 then cast were right on all of them. The result depends on the platform, so a test that pins one of these inputs is green on one CI runner and red on another.",
+   "requires": [
+    "torch"
+   ],
+   "fixed_in_release": null,
+   "repro": "import torch\nimport ulpwise\nxs = [x for x, _, _, _ in ulpwise.knife_edges('sqrt', 0.5, 1.0, 1e-3, 'f32', 64)]\nactual = torch.sqrt(torch.tensor(xs, dtype=torch.float32)).tolist()\nexpected = [ulpwise.sqrt_cr(x, 'f32') for x in xs]\n",
+   "check": {
+    "type": "equal"
+   },
+   "before_fix": "27 of the first 64 knife edges rounded down instead of up on torch 2.14.0+cpu (MKL, AVX512); builds without MKL VML may pass"
+  },
+  {
+   "id": "pytorch-198583-bessel-p1evl-leading-one",
+   "repo": "pytorch/pytorch",
+   "pr": null,
+   "issue": 198583,
+   "merged_at": null,
+   "kind": "coefficient",
+   "title": "bessel_j0, bessel_j1, bessel_y0, bessel_y1 and airy_ai drop the implied leading 1 of the Cephes p1evl denominators",
+   "symptom": "Ten Horner loops in Math.h start at 0.0 where Cephes' p1evl starts at 1.0, so the float64 results are off by up to 1e-6 absolute (2.4e-5 relative for j0 at 5.5, 1.0e-5 for y1 at 5.27, 3.3e-5 for airy_ai at -2.30); the OpInfo tests tolerate it through a float64 precisionOverride of 1e-5. Reported by the-Shallow for j0, j1 and y0; y1 and airy_ai added in the comments with the patch.",
+   "requires": [
+    "torch"
+   ],
+   "fixed_in_release": null,
+   "repro": "import torch\nx = torch.tensor([5.26993], dtype=torch.float64)\nactual = [\n    torch.special.bessel_j0(x).item(),\n    torch.special.bessel_j1(x).item(),\n    torch.special.bessel_y0(x).item(),\n    torch.special.bessel_y1(x).item(),\n    torch.special.airy_ai(torch.tensor([-2.30154], dtype=torch.float64)).item(),\n]\n# mpmath at 200 bits, rounded to float64\nexpected = [-0.086199871814967743, -0.34549232119438467, -0.33594130771681818, 0.054955745481668872, 0.025628209343452262]\n",
+   "check": {
+    "type": "max_ulp",
+    "dtype": "f64",
+    "max_ulp": 8
+   },
+   "before_fix": "[-0.08620011880207763, -0.34549245198818446, -0.3359412504444201, 0.05495518143365105, 0.025629044485656297] on torch 2.14.0 (1.8e10 to 2.5e14 ulp)"
+  },
+  {
+   "id": "kornia-4838-axis-angle-low-angle-terms",
+   "repo": "kornia/kornia",
+   "pr": null,
+   "issue": 4838,
+   "merged_at": null,
+   "kind": "truncation",
+   "title": "axis_angle_to_rotation_matrix low-angle branch is off by theta**3 / 6",
+   "symptom": "For theta**2 <= 1e-6 the branch returns I + [v]x + [v]x**2 / 2, so at theta = 9.99e-4 in float64 the matrix is 1.3e-10 from the rotation of its input and from quaternion_to_rotation_matrix(axis_angle_to_quaternion(v)), next to a general branch exact to 2.2e-16.",
+   "requires": [
+    "torch",
+    "kornia"
+   ],
+   "fixed_in_release": null,
+   "repro": "import torch\nimport kornia.geometry.conversions as C\naxis = torch.tensor([1.0, 2.0, 3.0], dtype=torch.float64) / 14.0**0.5\nv = (9.99e-4 * axis)[None]\nactual = C.axis_angle_to_rotation_matrix(v).flatten().tolist()\nexpected = C.quaternion_to_rotation_matrix(C.axis_angle_to_quaternion(v)).flatten().tolist()\n",
+   "check": {
+    "type": "allclose",
+    "atol": 1e-12,
+    "rtol": 0.0
+   },
+   "before_fix": "max |direct - quaternion route| = 1.33e-10 on kornia main 320f461"
+  },
+  {
+   "id": "kornia-4897-so3-se3-small-angle-digits",
+   "repo": "kornia/kornia",
+   "pr": null,
+   "issue": 4897,
+   "merged_at": null,
+   "kind": "cancellation",
+   "title": "So3.log, the So3 Jacobians and Se3.exp/log lose all their digits for small rotations",
+   "symptom": "So3.log uses 2 * acos(real) and Se3.exp/log form (1 - cos(theta)) / theta**2 and (theta - sin(theta)) / theta**3 directly, so in float32 a rotation of 1e-4 rad logs back to 0 and Se3.exp([1, 0, 0, 0, 0, 1e-4]) translates by (1, 0, 0) instead of (1, 5e-5, 0); the Jacobians are nan at the identity.",
+   "requires": [
+    "torch",
+    "kornia"
+   ],
+   "fixed_in_release": null,
+   "repro": "import torch\nfrom kornia.geometry.liegroup import Se3, So3\nrot = So3.exp(torch.tensor([[1e-4, 0.0, 0.0]], dtype=torch.float32))\nse = Se3.exp(torch.tensor([[1.0, 0.0, 0.0, 0.0, 0.0, 1e-4]], dtype=torch.float32))\nactual = [rot.log()[0, 0].item(), se.t[0, 1].item()]\nexpected = [1e-4, 5e-5]\n",
+   "check": {
+    "type": "allclose",
+    "atol": 0.0,
+    "rtol": 0.001
+   },
+   "before_fix": "[0.0, 0.0] on kornia main 7ddf731"
+  },
+  {
+   "id": "torchvision-9676-rotated-box-clamp-collapse",
+   "repo": "pytorch/vision",
+   "pr": null,
+   "issue": 9676,
+   "merged_at": null,
+   "kind": "ordering",
+   "title": "clamp_bounding_boxes collapses slightly tilted rotated boxes to a point",
+   "symptom": "_order_bounding_boxes_points picks the first corner with (y / y_max + 100 * x / x_max).min(), so for tilts within about half a degree of 0 or 180 the y term outweighs the x difference and a box that crosses the left edge clamps to [0, 200, 0, 0, 0] in both soft and hard mode.",
+   "requires": [
+    "torch",
+    "torchvision"
+   ],
+   "fixed_in_release": null,
+   "repro": "import torch\nfrom torchvision import tv_tensors\nfrom torchvision.transforms.v2 import functional as F\nbox = tv_tensors.BoundingBoxes(\n    torch.tensor([[13.355, 19.723, 75.347, 48.114, -0.2]]), format='CXCYWHR', canvas_size=(200, 300)\n)\nout = F.clamp_bounding_boxes(box)\nactual = [(out[0, 2] * out[0, 3]).item()]  # area of the clamped box\nexpected = [1.0]  # any positive area\n",
+   "check": {
+    "type": "sign"
+   },
+   "before_fix": "[0.0, 200.0, 0.0, 0.0, 0.0] on torchvision 0.29.0, area 0"
+  },
+  {
+   "id": "pytorch-198663-trigamma-float64-series-truncation",
+   "repo": "pytorch/pytorch",
+   "pr": null,
+   "issue": 198663,
+   "merged_at": null,
+   "kind": "truncation",
+   "title": "torch.polygamma(1, x) keeps about 9 digits in float64 because trigamma stops the asymptotic series at the 1/42 term",
+   "symptom": "trigamma(double) in Math.h shifts x up by 6 and sums the series through B_6, so the first dropped term, 1/(30 x^9), leaves a relative error near 1e-9 in every float64 result: 4.0e6 ulps at x = 0.9047, 557 of 800 positive inputs more than 4 ulps off, 3.0e7 ulps on negative non integers. The reference test tolerance for float64 is rtol = atol = 1e-7, about 4.5e8 ulps, so it never saw it.",
+   "requires": [
+    "torch"
+   ],
+   "fixed_in_release": null,
+   "repro": "import torch\nxs = torch.tensor([0.9047357242349293, 7.75, -2.75], dtype=torch.float64)\nactual = torch.polygamma(1, xs).tolist()\n# mpmath polygamma(1, x) at 200 bits, rounded to float64\nexpected = [1.9074856057949192, 0.13771379144765566, 19.433868949488463]\n",
+   "check": {
+    "type": "max_ulp",
+    "dtype": "f64",
+    "max_ulp": 8
+   },
+   "before_fix": "[1.9074856066876746, 0.13771379144953064, 19.43386894944752] on torch 2.14.0 (4.0e6, 6.8e4 and 1.2e4 ulp)"
+  },
+  {
+   "id": "pytorch-198663-trigamma-float32-reflection-argument",
+   "repo": "pytorch/pytorch",
+   "pr": null,
+   "issue": 198663,
+   "merged_at": null,
+   "kind": "rounding",
+   "title": "torch.polygamma(1, x) in float32 loses every digit for large negative x because the reflection evaluates sin(pi * x) at the rounded product",
+   "symptom": "pi * x is rounded to float32 before the sine, so at x = -60618.9921875 the sine is taken 0.0078 away from the right point and the result is 31981.7 for 16387.3; the poles at the non positive integers come out finite (1.3e15 at -1) instead of inf. Same code in the CUDA trigamma_string and calc_trigamma.",
+   "requires": [
+    "torch"
+   ],
+   "fixed_in_release": null,
+   "repro": "import torch\nxs = torch.tensor([-60618.9921875, -12345.03125], dtype=torch.float32)  # exact in float32\nactual = torch.polygamma(1, xs).tolist()\n# mpmath polygamma(1, x) at 200 bits, rounded to float32\nexpected = [16387.291015625, 1027.296142578125]\n",
+   "check": {
+    "type": "max_ulp",
+    "dtype": "f32",
+    "max_ulp": 8
+   },
+   "before_fix": "[31981.72265625, 967.1527709960938] on torch 2.14.0"
+  },
+  {
+   "id": "pytorch-198664-erfcx-negative-rounded-square",
+   "repo": "pytorch/pytorch",
+   "pr": null,
+   "issue": 198664,
+   "merged_at": null,
+   "kind": "rounding",
+   "title": "torch.special.erfcx is off by up to x*x/2 ulps for negative x because exp(x*x) is taken at the rounded product",
+   "symptom": "The negative branch returns 2 * exp(x * x) - erfcx_y100(400 / (4 - x)); the absolute rounding error of x * x becomes the relative error of exp, so the result is off by up to ulp(x * x) / 2: 44 float32 ulps at x = -8.44, 157 float64 ulps at x = -23.25, 504 float64 ulps at worst over 800 negative inputs. scipy.special.erfcx returns the same wrong float64 value, so only a multiprecision reference sees it.",
+   "requires": [
+    "torch"
+   ],
+   "fixed_in_release": null,
+   "repro": "import torch\nxs = torch.tensor([-23.25459451307119, -9.1], dtype=torch.float64)\nactual = torch.special.erfcx(xs).tolist()\n# exp(x * x) * erfc(x) from mpmath at 200 bits, rounded to float64\nexpected = [1.435935128289743e+235, 1.8405856937190915e+36]\n",
+   "check": {
+    "type": "max_ulp",
+    "dtype": "f64",
+    "max_ulp": 8
+   },
+   "before_fix": "[1.4359351282897875e+235, 1.8405856937190814e+36] on torch 2.14.0 (157 and 34 ulp)"
+  },
+  {
+   "id": "ultralytics-26330-obb-dataset-box-only-labels",
+   "repo": "ultralytics/ultralytics",
+   "pr": 26330,
+   "merged_at": "2026-09-25T22:12:25Z",
+   "kind": "crash",
+   "title": "OBB val and train on a dataset with plain box labels crashed deep in the validator or the loss instead of failing at load time",
+   "symptom": "With task=obb the loader builds the rotated boxes from the polygon points, so a detect dataset arrives as (0, 5) boxes next to n classes: yolo val crashed with IndexError in OBBValidator._prepare_batch and training with a TypeError in the loss. Segment datasets already raised a ValueError at load time; the fix applies the same box/segment count check when use_obb is set, with the task named in the message.",
+   "requires": [
+    "torch",
+    "ultralytics"
+   ],
+   "fixed_in_release": null,
+   "repro": "import tempfile\nfrom pathlib import Path\nimport cv2\nimport numpy as np\nfrom ultralytics.cfg import get_cfg\nfrom ultralytics.data import build_yolo_dataset\nroot = Path(tempfile.mkdtemp())\n(root / \"images\").mkdir()\n(root / \"labels\").mkdir()\ncv2.imwrite(str(root / \"images\" / \"0.jpg\"), np.zeros((32, 32, 3), np.uint8))\n(root / \"labels\" / \"0.txt\").write_text(\"0 0.5 0.5 0.4 0.4\\n\")  # a plain box row, not the 4 corners of an OBB\ndata = {\"names\": {0: \"a\"}, \"nc\": 1, \"channels\": 3}\ntry:\n    build_yolo_dataset(get_cfg(overrides={\"task\": \"obb\", \"imgsz\": 32}), str(root / \"images\"), 1, data, mode=\"val\")\n    actual = [\"no error at load time\"]\nexcept ValueError as e:\n    actual = [\"ValueError\" if \"OBB dataset requires equal numbers of boxes and segments\" in str(e) else str(e)]\nexpected = [\"ValueError\"]\n",
+   "check": {
+    "type": "equal"
+   },
+   "before_fix": "['no error at load time'] on ultralytics 8.4.163: the dataset loads and the crash comes later, in val or in the loss"
   }
  ]
-}
+}