Merge pull request #116 from TheHiddenObserver/agent/fix-logistic-cv-torch-p100

fix: repair Torch mixed-precision LogisticRegressionCV

Author: TheHiddenObserver

.github/workflows/test.yml

@@ -156,6 +156,31 @@ jobs:
       - name: Run complete CPU test tree
         run: python -m pytest dev/tests -q --tb=short
 
+  torch-cpu-logistic-cv:
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.9'
+      - name: Install Torch 2.0 CPU regression environment
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install "numpy<2" pytest
+          python -m pip install "torch==2.0.1+cpu" --extra-index-url https://download.pytorch.org/whl/cpu
+          python -m pip install -e .
+      - name: Confirm Torch regression environment
+        run: |
+          python - <<'PY'
+          import torch
+          assert torch.__version__.startswith("2.0.1")
+          assert not torch.cuda.is_available()
+          print("torch", torch.__version__, "device=cpu")
+          PY
+      - name: Run Issue 112 Torch CPU regressions
+        run: python -m pytest dev/tests/test_logistic_cv_torch_dtype.py -q --tb=short
+
   static-contracts:
     runs-on: ubuntu-latest
     steps:

CHANGELOG.md

@@ -2,6 +2,15 @@
 
 All notable changes to statgpu are documented here, organized by release and date.
 
+## 2026-08-07
+
+### PR #116 — Torch LogisticRegressionCV strict-CUDA repair
+
+- Fixed the mixed-precision Torch strict-CUDA `LogisticRegressionCV` failure by allocating batched IRLS parameters and ridge diagonals in the active CV working dtype and keeping candidate path outputs backend-native through validation scoring.
+- Added maintained regression coverage for float32/float64 CV, weighted and unweighted fitting, intercept/no-intercept paths, and the full CV selector, plus a Python 3.9 + Torch 2.0 CPU CI gate so optional-Torch coverage cannot silently skip.
+- Validated the unchanged numerical implementation head `e6e4846b06604ed53e65fc9afd9054bd5777098f` on Tesla P100 with PyTorch 2.0.0+cu117/CUDA 11.7 and CuPy 13.6.0: all 18 statgpu canonical CV backend runs succeeded without CPU fallback, including `LogisticRegressionCV` on NumPy, CuPy, and Torch.
+- Retained the historical pre-fix P100 failure source unchanged and registered the exact-head post-fix source under `results/pr116_p100/`; focused physical validation evidence is retained separately from dashboard timing data.
+
 ## 0.2.4 — 2026-08-06
 
 ### Logistic regression and GLM correctness

dev/benchmarks/RESULTS.md

@@ -2,6 +2,16 @@
 
 GPU performance data for statgpu. Results are from remote GPU testing unless noted otherwise.
 
+## Current canonical CV repair evidence — PR #116
+
+The exact numerical implementation head `e6e4846b06604ed53e65fc9afd9054bd5777098f` was physically validated on Tesla P100-SXM2-16GB with Python 3.9.16, PyTorch 2.0.0+cu117 / CUDA 11.7, and CuPy 13.6.0.
+
+- focused Torch CUDA validation: 4/4 cases passed, covering mixed-precision float32, float64, analytic weights, and `fit_intercept=False`;
+- canonical six-family CV rerun: all 18 statgpu NumPy/CuPy/Torch rows succeeded, with zero failed candidates/folds and converged final refits;
+- `LogisticRegressionCV` selected `C=0.1` on NumPy, CuPy, Torch, and sklearn;
+- raw exact-head evidence is retained under `results/pr116_p100/`;
+- the historical pre-fix P100 failure source remains registered separately and is not rewritten.
+
 ## Test Coverage (v23c — Latest)
 
 **1043/1043 ALL PASS (100%)**

dev/benchmarks/benchmark_coverage_matrix.json

@@ -201,12 +201,17 @@
     {
       "capability_id": "logistic-regression-cv",
       "label": "LogisticRegressionCV",
-      "status": "partial_canonical",
+      "status": "canonical_current",
       "source_ids": [
-        "cv-benchmark-20260807-1347184c988d"
+        "cv-benchmark-20260807-1347184c988d",
+        "cv-benchmark-pr116-20260807-bd8d512adced"
       ],
-      "issue": "#112",
-      "disposition": "Current canonical P100 evidence records NumPy and CuPy success and the explicit Torch strict-CUDA failure without CPU fallback. The production Torch defect is tracked by #112."
+      "representative_dimensions": [
+        "backend",
+        "pre_fix_failure",
+        "post_fix_success",
+        "physical_gpu"
+      ]
     },
     {
       "capability_id": "penalized-glm-cv",

dev/benchmarks/benchmark_source_catalog.json

@@ -119,6 +119,18 @@
       "issue": "#91",
       "reason": "Immutable P100 candidate retained for audit; its byte-identical SHA-protected canonical copy is registered in frontend_sources.json."
     },
+    {
+      "rule_id": "pr116-logistic-cv-focused-validation",
+      "priority": 19,
+      "path": "results/pr116_p100/focused_validation.json",
+      "classification": "not_canonical_ready",
+      "canonical_eligible": false,
+      "provenance_status": "validation_evidence",
+      "timing_protocol_status": "not_applicable",
+      "statistical_alignment_status": "accepted",
+      "issue": "#112",
+      "reason": "Exact-head P100 focused correctness evidence for PR #116 is retained for audit but is intentionally not a dashboard timing source."
+    },
     {
       "rule_id": "distribution-current-needs-audit",
       "priority": 30,

dev/benchmarks/frontend_sources.json

@@ -13,6 +13,12 @@
       "gpu": "Tesla P100-SXM2-16GB",
       "cpu": "x86_64",
       "host": "wE6lDe"
+    },
+    "remote-p100-pr116-20260807": {
+      "label": "Tesla P100 PR #116 CV validation — 2026-08-07",
+      "gpu": "Tesla P100-SXM2-16GB",
+      "cpu": "x86_64",
+      "host": "wE6lDe"
     }
   },
   "frameworks": {
@@ -83,6 +89,10 @@
     "cv-benchmark-20260807": {
       "label": "Cross-validation benchmark — 2026-08-07",
       "env_id": "remote-p100-cv-20260807"
+    },
+    "cv-benchmark-pr116-20260807": {
+      "label": "Cross-validation benchmark after PR #116 repair — 2026-08-07",
+      "env_id": "remote-p100-pr116-20260807"
     }
   },
   "sources": [
@@ -205,6 +215,21 @@
       "measurement_git_sha": "ad2cf88d1d443a53eeb5207c33c4ee4f25de2400",
       "raw_git_sha": "unknown",
       "provenance_note": "The immutable P100 runner output could not resolve VCS metadata and therefore records git_sha=unknown. The rerun was executed from the ad2cf88 benchmark implementation tree; repository comparison confirms no file-level tree change across the intervening diagnostic add/remove commits."
+    },
+    {
+      "source_id": "cv-benchmark-pr116-20260807-bd8d512adced",
+      "comparison_id": "cv-benchmark-pr116-20260807",
+      "path": "results/pr116_p100/cv_benchmark_pr116_p100.json",
+      "sha256": "bd8d512adced442b066de20fb2c31f3f50b19f271d6d0de6bd0d82e9b4cd9be8",
+      "parser": "cv_benchmark",
+      "parser_version": "1.1",
+      "env_id": "remote-p100-pr116-20260807",
+      "required": true,
+      "allowed_issue_codes": [],
+      "source_date": "2026-08-07",
+      "measurement_git_sha": "e6e4846b06604ed53e65fc9afd9054bd5777098f",
+      "raw_git_sha": "e6e4846b06604ed53e65fc9afd9054bd5777098f",
+      "provenance_note": "Physical PR #116 validation was executed on Tesla P100 from exact numerical implementation head e6e4846b06604ed53e65fc9afd9054bd5777098f. The artifact records that SHA directly; the historical pre-fix P100 source remains registered separately."
     }
   ]
 }

dev/plans/logistic_cv_torch_cuda_fix_plan.md

@@ -0,0 +1,160 @@
+# LogisticRegressionCV Torch strict-CUDA repair plan
+
+Issue: #112  
+Baseline: `master` at `37f643a68ded71a33f8eea5ed8217aab42c650e1`  
+Scope: correctness repair before the next roadmap feature package (#93)
+
+## 1. Why this is the next stage
+
+The benchmark/dashboard sequence through PR #115 is complete. The roadmap normally moves next to Panel P1 (#93), but its own priority rules put correctness and public-contract risk ahead of feature breadth. Canonical CV evidence currently records one maintained backend defect: `LogisticRegressionCV` fails on Torch strict CUDA while the corresponding NumPy, CuPy, and sklearn rows succeed. Therefore #112 is treated as a bounded correctness blocker before starting #93.
+
+This change does not reopen dashboard performance work and does not add a new statistical feature.
+
+## 2. Impact classification
+
+Active gates:
+
+- backend/device/dtype locality;
+- cross-validation;
+- numerical correctness/convergence;
+- tests and compatibility;
+- user-facing documentation/changelog;
+- physical-GPU validation.
+
+Inactive gates:
+
+- public constructor/API shape: no public arguments or return types should change;
+- formula semantics: no formula/model-matrix path changes are planned;
+- inference definition: final-refit inference contract is unchanged;
+- benchmark/performance claims: no speedup claim is planned.
+
+Capability decision:
+
+- backend: `three-backend` (existing capability, Torch path repaired);
+- CV: `supported`;
+- inference: `supported` for the final refit exactly as before;
+- formula: unchanged;
+- benchmark: correctness evidence required, performance claim not required.
+
+## 3. Root cause established from current source
+
+`_select_logistic_c_cv()` defaults to `gpu_cv_mixed_precision=True`, so the GPU CV working design is `float32`.
+
+In `_solve_logistic_path_gpu_from_batch()` the current Torch path then creates:
+
+- `params = backend.zeros(...)` without a dtype, and
+- `reg_diag = backend.full(...)` without a dtype.
+
+`TorchBackend.zeros/full` default to `torch.float64`. The first matrix multiply therefore combines a `float32` design matrix with `float64` parameters. Torch requires matching matrix-multiplication dtypes, so strict Torch CUDA fails before completing the first candidate. CuPy is more permissive about mixed-dtype arithmetic, which explains the backend-specific disposition seen in the canonical benchmark.
+
+The same helper also converts every fitted coefficient vector/intercept to NumPy inside the candidate/fold loop and then converts them back to the GPU backend for scoring. This does not cause the reported failure, but it is an unnecessary device round trip in the exact code being repaired and increases the risk of dtype drift.
+
+A repository-wide call-site search found exactly one caller of `_solve_logistic_path_gpu_from_batch()`: `_select_logistic_c_cv()` in the same module. Therefore changing this private helper to keep its return batches backend-native is a bounded internal refactor, not a public API change. Both `TorchBackend` and `CuPyBackend` provide the required `stack`, `copy`, `zeros`, and dtype-aware array-creation primitives.
+
+## 4. Implementation plan
+
+### A. Make the batched IRLS working dtype explicit
+
+In `statgpu/linear_model/cv/_logistic_cv.py`:
+
+- create `params` with `dtype=X_design.dtype`;
+- create regularization diagonals with `dtype=XtWX.dtype`;
+- keep coefficient/intercept batches in backend-native arrays through scoring;
+- use backend-native stacking so the returned path batch preserves dtype and device;
+- only transfer the per-fold loss vector to NumPy when populating the public `loss_path` result;
+- preserve the current objective, intercept non-penalization rule, folds, C grid, sample-weight semantics, convergence tolerance, and strict no-CPU-fallback behavior.
+
+No statistical definition changes are allowed in this repair.
+
+### B. Add deterministic regression coverage that does not require hosted CUDA
+
+Add focused tests using `TorchBackend(device="cpu")` to exercise the internal batched helper on both working-dtype modes:
+
+- default mixed precision: `float32`;
+- `gpu_cv_mixed_precision=False` analogue: `float64`.
+
+The tests should prove:
+
+- the helper no longer raises a Float/Double dtype mismatch;
+- returned coefficient/intercept batches remain Torch tensors on the selected backend and keep the requested working dtype;
+- candidate outputs are finite and have the expected shapes;
+- the path solver itself performs no `backend.to_numpy()` conversion;
+- float32 and float64 paths agree to a documented mixed-precision tolerance on the same deterministic problem.
+
+Add/extend public CV tests to preserve:
+
+- CPU/CuPy/Torch selection semantics where the backend is available;
+- explicit-device no-fallback behavior;
+- sample-weight behavior;
+- deterministic candidate selection and transactional final refit.
+
+The private return-type change is safe only while the single-caller invariant holds; the regression should exercise that consuming path rather than expose the helper publicly.
+
+### C. Check compatibility and numerical parity
+
+Run the strongest locally available evidence:
+
+- targeted LogisticRegressionCV tests;
+- Torch CPU internal float32/float64 regressions;
+- maintenance/static tests covering CV backend routing;
+- full hosted CPU/compatibility workflows on the PR head.
+
+Numerical checks should compare the same C grid/folds and ensure the repaired path does not alter the declared loss or selection semantics beyond normal mixed-precision tolerance.
+
+### D. Documentation and issue state
+
+Update the root/EN/CN changelogs with the repaired strict-Torch CV behavior once implementation is validated.
+
+Do **not** edit the canonical `2026-08-07` benchmark source from `failed` to `success` without a new physical-GPU measurement. Historical measured evidence remains immutable.
+
+Issue #112 should close only after a current-source physical Torch CUDA reproduction succeeds. If physical GPU access is unavailable in this run, finish with `PARTIAL_REMOTE_PENDING` and leave #112 open with the exact rerun command/evidence needed.
+
+## 5. Physical-GPU acceptance
+
+Required for `COMPLETE`:
+
+- Torch CUDA on a real NVIDIA GPU, preferably the original Tesla P100 / Torch 2.0.x compatibility environment or an equally strict supported environment;
+- run the canonical CV reproduction for `LogisticRegressionCV` with default `gpu_cv_mixed_precision=True`;
+- also smoke the `gpu_cv_mixed_precision=False` path on the same source head;
+- confirm strict Torch execution succeeds without CPU fallback;
+- compare selected C / CV loss against NumPy or CuPy within a documented mixed-precision tolerance;
+- record software/hardware/source SHA and the exact command.
+
+A fresh canonical benchmark artifact may be added only from an actual rerun. The old failed artifact remains historical evidence.
+
+## 6. Plan review/fix closure criteria
+
+Review the plan before implementation for:
+
+1. whether the proposed fix changes any statistical definition;
+2. whether it accidentally weakens strict device semantics;
+3. whether it leaves another Torch mixed-dtype boundary in fit or scoring;
+4. whether tests can catch the original failure on CPU-only CI;
+5. whether both float32 and float64 working modes are covered;
+6. whether the private backend-native return change has any caller outside this module;
+7. whether the plan improperly rewrites historical benchmark evidence;
+8. whether the change should remain bounded to #112 rather than becoming a general CV refactor.
+
+First plan review findings and fixes:
+
+- **MEDIUM / TEST — fixed:** the initial plan tested only the default float32 path. It now requires both float32 and float64 working modes plus cross-dtype numerical parity.
+- **MEDIUM / MAINT — fixed:** the initial plan changed the private helper return representation without establishing call-site scope. Repository search confirms exactly one caller in the same module, and CuPy/Torch backend primitives support the bounded backend-native stacking change.
+
+Implementation may begin only after a fresh re-review finds no new in-scope plan issue.
+
+After implementation, run `.claude/skills/code-review.md` in auto-fix mode and repeat targeted validation/re-review until no new CRITICAL/HIGH or in-scope MEDIUM issue is found.
+
+## 7. Non-goals
+
+- no Panel #93 implementation in the same PR;
+- no general `_penalized_cv.py` decomposition;
+- no solver rewrite;
+- no new penalty, formula, or inference behavior;
+- no dashboard optimization or schema change;
+- no fabricated or reconstructed benchmark success row;
+- no performance claim without a new measured artifact.
+
+## 8. Expected exit
+
+- `COMPLETE` only if local/hosted gates and physical Torch CUDA validation all pass;
+- otherwise `PARTIAL_REMOTE_PENDING` is acceptable when the implementation/review is clean and only physical-GPU evidence is missing.

dev/tests/test_benchmark_catalog.py

@@ -76,6 +76,14 @@ def test_catalog_retains_distinct_noncanonical_dispositions(entries):
     assert distribution["classification"] == "not_canonical_ready"
     assert distribution["issue"] == "#101"
 
+    focused = next(
+        entry for entry in entries
+        if entry["path"] == "results/pr116_p100/focused_validation.json"
+    )
+    assert focused["classification"] == "not_canonical_ready"
+    assert focused["provenance_status"] == "validation_evidence"
+    assert focused["issue"] == "#112"
+
 
 def test_coverage_matrix_is_referentially_complete(coverage_matrix, manifest):
     from dev.benchmarks.frontend_data.catalog import validate_coverage_matrix
@@ -84,8 +92,11 @@ def test_coverage_matrix_is_referentially_complete(coverage_matrix, manifest):
     rows = {row["capability_id"]: row for row in coverage_matrix["capabilities"]}
     assert rows["ridge-cv"]["status"] == "canonical_current"
     assert rows["ridge-cv"]["source_ids"] == ["cv-benchmark-20260807-1347184c988d"]
-    assert rows["logistic-regression-cv"]["status"] == "partial_canonical"
-    assert rows["logistic-regression-cv"]["issue"] == "#112"
+    assert rows["logistic-regression-cv"]["status"] == "canonical_current"
+    assert rows["logistic-regression-cv"]["source_ids"] == [
+        "cv-benchmark-20260807-1347184c988d",
+        "cv-benchmark-pr116-20260807-bd8d512adced",
+    ]
     assert rows["distribution-api"]["issue"] == "#101"
     assert rows["feature-selection-knockoff"]["issue"] == "#103"
     assert rows["penalized-coxph"]["issue"] == "#107"
@@ -108,9 +119,9 @@ def test_inventory_v2_reconciles_literal_counts(
     assert inventory["inventory_version"] == "2.0"
     assert inventory["discovered_json_artifacts"] == len(entries)
     assert inventory["classified_candidate_sources"] == len(entries)
-    assert inventory["registered_sources"] == len(manifest["sources"]) == 9
-    assert inventory["available_registered_sources"] == 9
-    assert inventory["parsed_registered_sources"] == 9
+    assert inventory["registered_sources"] == len(manifest["sources"]) == 10
+    assert inventory["available_registered_sources"] == 10
+    assert inventory["parsed_registered_sources"] == 10
     assert inventory["eligible_sources"] == (
         inventory["registered_sources"]
         + inventory["eligible_unregistered_sources"]

dev/tests/test_benchmark_frontend_data.py

@@ -159,7 +159,7 @@ class TestManifestMode:
     def test_manifest_loads_with_exact_current_sources(self, manifest):
         assert manifest is not None
         assert manifest["minimum_source_date"] == "2026-06-01"
-        assert len(manifest["sources"]) == 9
+        assert len(manifest["sources"]) == 10
         assert all(source.get("source_date") for source in manifest["sources"])
 
     def test_canonical_generate(self, generator, manifest, results_dir):
@@ -174,11 +174,11 @@ def test_canonical_generate(self, generator, manifest, results_dir):
         assert output["frameworks"]
         assert output["comparisons"]
         assert output["meta"]["generation_id"]
-        assert report["files_seen"] == 9
-        assert report["files_parsed"] == 9
-        assert inventory["registered_sources"] == 9
-        assert inventory["available_sources"] == 9
-        assert inventory["parsed_sources"] == 9
+        assert report["files_seen"] == 10
+        assert report["files_parsed"] == 10
+        assert inventory["registered_sources"] == 10
+        assert inventory["available_sources"] == 10
+        assert inventory["parsed_sources"] == 10
         assert not any(
             run["source"]["source_id"].startswith("transitional:")
             for run in output["runs"]