Skip to content

docs: stop attributing the supernodal allocation and the whole-suite failures - #339

Merged
shinaoka merged 4 commits into
mainfrom
docs/337-unverified-claims
Nov 9, 2026
Merged

shinaoka merged 4 commits into
mainfrom
docs/337-unverified-claims

Conversation

@shinaoka

@shinaoka shinaoka commented Nov 9, 2026 •

Copy link
Copy Markdown
Member

What this changes

Two sentences that #337 left on main, narrowed to what was measured.

1. The 468080 B supernodal allocation. CHANGELOG.md and PATCHSET.md said it is the supernodal symbolic workspace and
not the COLAMD one. The supernodal helper for that arm requests four n-element index arrays
(lu.rs:567-573, qr.rs:433-439, cholesky.rs:2373-2376) — 64000 B at m = n = 2000 with 8-byte indices — but that helper is
only one component of the top-level analysis request, which also carries the transpose storage and the largest temporary. The
helper alone cannot account for 468080 B, so it has to come from somewhere else inside symbolic analysis. The simplicial QR
helper, by contrast, requests three arrays (qr.rs:1698-1703), so the request is not one shared four-array shape either.
The number was measured; the attribution was inferred from it. It now says the allocation did not change and that its call site was
not traced.

2. The whole-suite failures. PATCHSET.md said the process-wide allocation counters in no_step_alloc and
triangular_solve::aliased_rhs::staged_solve_is_bitwise_the_in_place_one "pass standalone and flake only inside the whole-suite
parallel run". no_step_alloc is its own test binary, so another test binary cannot perturb its counter directly — the obvious
explanation is not available. The latter test also asserts the opposite of what the ledger sentence said: triangular_solve.rs:1131-1135
requires ran_kib == 0, i.e. that a 1 KiB stride is not staged. It now says both pass standalone, both were seen to fail in the
whole-suite run, and what makes them fail there was not identified.

Neither change touches code, and neither weakens a guarantee: the fix in #337 is unaffected, and the tests that pin the two
directions of the COLAMD request are untouched.

Verification

$ git diff --stat 1825b7e20c0baacf69e8f217fcb5c069c35ae180...0462ef9212dfbfaa1fb90315cf86a5f19d839fe9
 CHANGELOG.md | 3 ++-
 PATCHSET.md  | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)
$ git diff --check 1825b7e2...0462ef92
(no output)

No code changed, so nothing in the repository's per-PR checks exercises these edits: cargo test --doc runs Rust doctests and
scripts/check-migration-examples.py compares the migration guides with examples, and neither reads CHANGELOG.md or
PATCHSET.md. What was actually checked by hand is the diff above plus a line-by-line read of the two changed paragraphs against
triangular_solve.rs:1131-1135 (ran_kib == 0), qr.rs:1698-1703 (StackReq::new::<I>(ncols).array(3)), and
lu.rs:567-573 / qr.rs:433-439 / cholesky.rs:2373-2376 (the four-array supernodal helper).

The allocation-tracing experiment the review asked for (run issue #322's counting program against e756f13 and b989876, force the
supernodal arm on both, and trace the 468080 B allocation to its call site) is deliberately not part of this PR: it belongs in
an issue where its result can be read on its own, not in a sentence that guesses at it now.

@shinaoka

shinaoka commented Nov 9, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 2
UNVERIFIED: 2

Critical (must not merge)

none

Needs changes

  • PATCHSET.md:195–199 — The inserted newlines split one ledger entry into five table rows. Reproduced by fetching this file at 8285eaee46d79df9ea61aeef07aeffebf9662aef and submitting it to GitHub’s POST /markdown endpoint with mode: "gfm": the evidence cell ends at “same four-array request as the”, and each subsequent physical line becomes a separate <tr> with its text in the first column and four empty cells. The test results and failure qualifications therefore leave the entry’s evidence column. Keep the entire table row on one physical line.

  • PATCHSET.md:195–196 — The replacement incorrectly describes the top-level analysis request as a four-array request. Reproduce by evaluating faer/src/sparse/linalg/lu.rs:2393–2411 or qr.rs:2421–2440 for the stated 64-bit input: the full request is 8 × (4×2000 + 2001 + 7990 + 12000) = 239928 B, not the four-array helper’s 64000 B. The cited supernodal helpers delegate to cholesky.rs:2373–2376; that helper is only one component inside the maximum, and the simplicial QR helper actually requests three arrays (qr.rs:1698–1703). State that the full initial request is independent of the selected arm, rather than equating that request with the nested four-array helper.

Unverified claims

  • CHANGELOG.md:19–21, PATCHSET.md:195 — “468080 B … did not change” remains a historical measurement claim, not something this diff establishes. PR perf(sparse): stop requesting the COLAMD workspace when the ordering is supplied (#322) #337 contains reported before/after output, but the allocation tests force simplicial analysis (faer/tests/sparse_symbolic_colamd_workspace.rs:75–82) and cannot validate the supernodal measurement. Verification requires running issue Sparse symbolic LU/QR with an explicit column ordering still allocate the COLAMD workspace #322’s release-mode counting program against e756f13 and b989876, forcing supernodal LU and QR and comparing the recorded maxima. I did not run that comparison; cannot read a linked raw measurement artifact establishing those executions.

  • PATCHSET.md:197–198 — The standalone passes, whole-suite failures, and identical origin/main LQ failure remain unverified execution claims. PR perf(sparse): stop requesting the COLAMD workspace when the ordering is supplied (#322) #337 reports these outcomes, but neither this documentation diff nor the test source establishes them. Reproduce with commit-stamped logs for cargo test -p t4a-faer -j6 --no-fail-fast on both revisions, plus separate invocations of --test no_step_alloc and --lib staged_solve_is_bitwise_the_in_place_one. Cannot read linked original execution logs establishing the revisions and outcomes; standalone passes alone would not establish the failure mechanism.

Checked and fine

  • Reviewed head 8285eaee46d79df9ea61aeef07aeffebf9662aef; the changed-file list contains only CHANGELOG.md and PATCHSET.md.
  • faer/tests/no_step_alloc.rs:16–17,39–42,68–70 defines a process-local allocator counter and one test; another test binary cannot directly update that counter.
  • Not checked: local Cargo tests, mutation tests, or allocation reproductions; at inspection, build and testing-stable-ubuntu-latest were still running, so no completed-suite result was available.

Reviewed head: 8285eaee46d79df9ea61aeef07aeffebf9662aef at 2026-11-09T05:28:07Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

@shinaoka

shinaoka commented Nov 9, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 1
UNVERIFIED: 2

Critical (must not merge)

none

Needs changes

Unverified claims

  • CHANGELOG.md:19–21, PATCHSET.md:195 — The supernodal largest allocation remains exactly 468080 B. Removing its attribution does not establish the measurement itself. The unchanged regression tests force simplicial analysis (faer/tests/sparse_symbolic_colamd_workspace.rs:75–82), so their passes cannot verify this supernodal number. PR perf(sparse): stop requesting the COLAMD workspace when the ordering is supplied (#322) #337 contains reported before/after output, but I did not independently reproduce it. Verify: run issue Sparse symbolic LU/QR with an explicit column ordering still allocate the COLAMD workspace #322’s release-mode counting program against e756f13 and b989876, forcing supernodal LU and QR, and retain revision-stamped output.

  • PATCHSET.md:197 — The LQ failure “fails identically on origin/main.” The accessible /private/tmp/faer322-test2.log and faer322-test3.log record failures, but do not establish the baseline commit needed for that comparison; cannot read a commit-stamped baseline log proving the assertion. Exact-head Linux nextest passes do not reproduce the historical macOS failure. Verify: run cargo test -p t4a-faer -j6 --test lq_no_alloc lq_allocates_nothing_60x300 on the fixed baseline e756f13 and b989876 with the same toolchain and environment, retaining the commit IDs and failing allocation vectors.

Checked and fine

  • The commit changes only CHANGELOG.md and PATCHSET.md: 7 additions, 2 deletions; git diff --check reports no whitespace errors.
  • CI run 42566074942 targets the exact reviewed head and reports 872 passed, 162 skipped; both COLAMD regression tests and all three named allocation tests passed.
  • Local Cargo tests, mutation tests, and allocation A/B runs were not rerun; CI success does not validate the Markdown table or the historical runtime claims above.

Reviewed head: 8285eaee46d79df9ea61aeef07aeffebf9662aef at 2026-11-09T05:58:45Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

@shinaoka

shinaoka commented Nov 9, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 1
UNVERIFIED: 2

Critical (must not merge)

none

Needs changes

  • PATCHSET.md:195–199 — Hard-wrapping the table row moves the corrections into four separate rows. GitHub’s Markdown renderer puts lines 196–199 into the first column of new rows, leaving the allocation explanation unfinished in the original evidence cell and separating the failure caveat from its entry. Reproduced against GitHub’s rendering API:
    git show 8285eaee46d79df9ea61aeef07aeffebf9662aef:PATCHSET.md \
      | jq -Rs '{text: ., mode: "gfm"}' \
      | gh api markdown --input -
    The returned HTML contains separate <tr> elements starting with “simplicial one,” “attributed here,” “seen to fail,” and “so another test binary.” Keep this table entry on one physical line; use <br> if visual breaks are needed.

Unverified claims

  • CHANGELOG.md:19–21, PATCHSET.md:195 — The reported allocation sizes and “did not change” remain experimentally unverified by this diff. The unchanged regression test forces the simplicial path on a 100 × 100 input and checks inequalities against order_scratch; it does not establish the 2,000 × 2,000 measurements or the unchanged 468080 B supernodal maximum. Verification requires running issue Sparse symbolic LU/QR with an explicit column ordering still allocate the COLAMD workspace #322’s counting program at e756f13 and b989876, explicitly forcing each arm and recording both results. No such comparison was run in this review.

  • PATCHSET.md:197–198 — “Both pass standalone at this revision” and the historical whole-suite failures are not established by the supplied verification. The PR provides a diff statistic, not execution logs for these statements. To verify, run cargo test -p t4a-faer --test no_step_alloc, run the named triangular-solve test alone, and compare with the recorded cargo test -p t4a-faer -j6 output under the same toolchain and environment. A successful present-day run cannot establish the asserted historical failures.

Checked and fine

  • The supplied commit changes only the two documented files; its statistics match the PR body, and git diff --check passes.
  • GitHub reports eight successful checks for the exact supplied SHA; inspected PR workflows do not render PATCHSET.md, so their green status does not cover the reproduced table defect.
  • Not checked: historical allocation measurements, standalone failure reproductions, or mutation tests; the retained runtime claims remain unverified.

Reviewed head: 8285eaee46d79df9ea61aeef07aeffebf9662aef at 2026-11-09T06:01:52Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

@shinaoka

shinaoka commented Nov 9, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 1
UNVERIFIED: 2

Critical (must not merge)

none

Needs changes

  • PATCHSET.md:195 — The replacement introduces another incorrect workspace description. “The top-level analysis request … is the same four-array request as the simplicial one” conflates a nested supernodal scratch helper with the complete allocation request. Reproduce: follow the cited helpers to cholesky.rs:2376, which requests four arrays, then inspect lu.rs:2397–2412 and qr.rs:2425–2441: the actual top-level requests also contain persistent arrays, transpose storage, and a maximum over several scratch requirements. Furthermore, the simplicial QR helper requests three arrays (qr.rs:1698–1703), not four. For 64-bit indices and the stated input, the supernodal helper requests 64000 B, whereas the complete analysis request is 239928 B. Replace the sentence with the precise distinction: the top-level request is independent of the selected arm, and the four-array supernodal helper does not increase its maximum.

Unverified claims

  • CHANGELOG.md:20–21, PATCHSET.md:195 — The unchanged 468080 B allocation remains a reported measurement, not independently established evidence. The new wording identifies its provenance, but neither this diff nor the existing tests establishes that value: faer/tests/sparse_symbolic_colamd_workspace.rs:75–82 forces simplicial analysis, and its assertions use n=100 rather than n=2000. Reproduce: run issue Sparse symbolic LU/QR with an explicit column ordering still allocate the COLAMD workspace #322’s release-mode counting program against e756f13 and b989876, forcing supernodal LU and QR, and retain revision-stamped output. I did not execute that comparison; cannot read a raw allocation trace from the supplied or linked PR artifacts.

  • PATCHSET.md:195 — “Both pass standalone at this revision” and the retained identical-baseline LQ failure claim lack revision-stamped execution evidence. PR perf(sparse): stop requesting the COLAMD workspace when the ordering is supplied (#322) #337 reports these observations, but this PR supplies no standalone results for 60ddd902, and its verification section explicitly reports no reruns. Reproduce: on the reported macOS environment, run cargo test -p t4a-faer --test no_step_alloc, the filtered staged_solve_is_bitwise_the_in_place_one library test, and the LQ test; compare the latter against the exact baseline commit rather than a moving origin/main. Cannot read original commit-stamped standalone and baseline logs establishing those statements.

Checked and fine

  • The exact-head changed-file list contains only CHANGELOG.md and PATCHSET.md; no source or test changes.
  • At inspection, build and testing-stable-ubuntu-latest were still running; completed checks do not establish an all-green result.
  • Not checked: local builds, mutation tests, or runtime reproductions; the historical allocation and failure observations remain unverified.

Reviewed head: 60ddd90288343dc3479978a52d16ea90e95d52c5 at 2026-11-09T06:07:30Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

@shinaoka

shinaoka commented Nov 9, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 2
UNVERIFIED: 2

Critical (must not merge)

none

Needs changes

  • PATCHSET.md:195 — The triangular-solve test is still incorrectly described as an allocation counter. staged_solve_is_bitwise_the_in_place_one measures stage::STAGED, which counts staged solve nodes, not heap allocations (faer/src/linalg/triangular_solve.rs:507–510,579,1108–1119). Reproduce: inspect those increments and the recorded failure in /private/tmp/faer322-test3.log:908–913: the assertion is “a 1 KiB stride was staged,” with left: 2, not an allocation assertion. This wording preserves a false description in the very sentence being corrected; distinguish the allocation counter in no_step_alloc from the staging counter in the triangular-solve test.

  • PATCHSET.md:195 — The replacement explanation confuses the supernodal helper’s four-array request with the complete top-level analysis request. The cited helper requests four arrays, but the enclosing request also includes four persistent arrays, transpose storage, and a maximum of several temporary requests (faer/src/sparse/linalg/lu.rs:2392–2412, qr.rs:2420–2441); the simplicial QR helper itself requests three, not four, arrays (qr.rs:1698–1704). Reproduce: substitute m=n=2000, nnz=7990, and 8-byte indices: the supernodal helper requests 64000 B, whereas the complete analysis request is 64000 + 79928 + 96000 = 239928 B. Replace “the same four-array request as the simplicial one” with the supported statement that the complete top-level request is independent of the selected arm; the PR body repeats the same error.

Unverified claims

  • CHANGELOG.md:19–21, PATCHSET.md:195 — The reported 468080 B allocation and its before/after equality remain unverified runtime claims. PR perf(sparse): stop requesting the COLAMD workspace when the ordering is supplied (#322) #337 contains the reported numbers, but this diff supplies neither a fresh measurement nor an allocation trace; the unchanged regression tests force simplicial analysis (faer/tests/sparse_symbolic_colamd_workspace.rs:75–82). Reproduce: run issue Sparse symbolic LU/QR with an explicit column ordering still allocate the COLAMD workspace #322’s release-mode counting program against e756f13 and b989876, forcing supernodal LU and QR, and retain allocation traces. I did not execute that comparison; cannot read a linked raw trace. The new text explicitly acknowledges this limitation.

  • PATCHSET.md:195 — “Both pass standalone at this revision” is not established by the inspected evidence. The available local logs contain whole-suite failures, while exact-head CI runs the tests through nextest; neither establishes standalone passes under the original macOS Cargo environment. Reproduce: at 60ddd902, run cargo test -p t4a-faer --test no_step_alloc and cargo test -p t4a-faer --lib staged_solve_is_bitwise_the_in_place_one -- --exact linalg::triangular_solve::aliased_rhs::staged_solve_is_bitwise_the_in_place_one, retaining the SHA, toolchain, environment, and output. Cannot read commit-stamped standalone-pass logs.

Checked and fine

  • git diff 1825b7e 60ddd902 --name-only lists only CHANGELOG.md and PATCHSET.md; source and tests are unchanged.
  • Exact-head CI run 42570690132 reports 872 passed and 162 skipped, including both COLAMD tests and both discussed counter tests; this is Linux nextest evidence, not reproduction of the macOS failures.
  • Not checked locally: builds, allocation reproductions, mutation tests, or standalone reruns; the historical measurements and failure causes remain unresolved.

Reviewed head: 60ddd90288343dc3479978a52d16ea90e95d52c5 at 2026-11-09T06:31:28Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

@shinaoka

shinaoka commented Nov 9, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 2
UNVERIFIED: 2

Critical (must not merge)

none

Needs changes

  • PATCHSET.md:195 — The replacement reverses the triangular-solve assertion. It says the test “asserts that a 1 KiB stride was staged,” but faer/src/linalg/triangular_solve.rs:1131–1135 asserts ran_kib == 0: that stride must not be staged. Reproduce: inspect that assertion and /private/tmp/faer322-test3.log:908–913, which records its failure with left: 2, right: 0; “a 1 KiB stride was staged” is the failure message, not the expected behavior. Change the sentence to “asserts that a 1 KiB stride was not staged.”

  • faer/src/sparse/linalg/lu.rs:2397–2412, faer/src/sparse/linalg/qr.rs:2425–2441 — The PR body retains the incorrect “top-level … four-array request” explanation removed from the ledger. The complete request includes four persistent arrays, transpose storage, and a maximum over temporary requests; the four-array supernodal helper is only one component, and the simplicial QR helper actually requests three arrays (qr.rs:1698–1703). Reproduce: substitute m=n=2000, nnz=7990, and 8-byte indices: the complete request is 8 × (8000 + 2001 + 7990 + 12000) = 239928 B, whereas the four-array helper requests 64000 B. Correct the PR body to say that the complete initial request is independent of the selected arm, without equating it with that helper.

Unverified claims

  • CHANGELOG.md:19–21, PATCHSET.md:195 — The unchanged 468080 B supernodal maximum remains a reported measurement, not an independently verified result. PR perf(sparse): stop requesting the COLAMD workspace when the ordering is supplied (#322) #337 reports before/after values, but faer/tests/sparse_symbolic_colamd_workspace.rs:75–82 forces simplicial analysis on the smaller test input. Verify: run issue Sparse symbolic LU/QR with an explicit column ordering still allocate the COLAMD workspace #322’s release-mode counting program against e756f13 and b989876, force supernodal LU and QR, and retain revision-stamped allocation output. I did not run that comparison; cannot read a linked raw measurement artifact establishing those executions. The replacement explicitly acknowledges the lack of remeasurement.

  • PATCHSET.md:195 — “Both pass standalone at this revision” and the identical-baseline LQ failure lack revision-stamped execution evidence. The accessible local logs establish whole-suite failures, but do not establish standalone passes at 874c173 or identify the baseline used for “fails identically on origin/main.” Verify: retain SHA/toolchain-stamped standalone runs of no_step_alloc and the filtered triangular-solve test, and compare the LQ test on fixed commits e756f13 and b989876 under the same environment. Cannot read commit-stamped standalone and baseline logs proving these assertions.

Checked and fine

  • At 874c173, the base-to-head diff changes only the two Markdown files; git diff --check reports no whitespace errors.
  • Exact-head CI run 42574074128 reports 872 passed and 162 skipped, including both COLAMD tests and all three discussed tests; its Linux nextest execution does not reproduce the historical macOS Cargo run.
  • Not checked locally: builds, mutation tests, allocation comparisons, or standalone reruns; the historical execution claims remain unverified.

Reviewed head: 874c1735805b3a52035ff1d17bf9fd4c3d999468 at 2026-11-09T07:08:59Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

@shinaoka

shinaoka commented Nov 9, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 2
UNVERIFIED: 2

Critical (must not merge)

none

Needs changes

  • The verification transcript does not match the submitted diff (PATCHSET.md:195, PR body’s Verification block). Run git diff --stat 1825b7e20c0baacf69e8f217fcb5c069c35ae180...0462ef9212dfbfaa1fb90315cf86a5f19d839fe9: PATCHSET.md reports 2 +-, not 6 +++++-; the complete diff has 3 insertions and 2 deletions, not the 7 insertions and 2 deletions implied by the body. Replace the stale transcript with the actual output.

  • The claimed documentation checks do not validate either changed document (.github/workflows/ci.yml:31–37, scripts/check-migration-examples.py:7–27; claim in PR body’s Verification paragraph). Inspect those steps: the Python checker compares migration guides with examples, and cargo test --doc runs Rust doctests; neither checks CHANGELOG.md or PATCHSET.md. Reproduce with git grep -n -E 'CHANGELOG|PATCHSET' 0462ef9 -- .github/workflows scripts/check-migration-examples.py, which returns no matches. Remove the implication that existing CI validates these edits and state the manual checks actually performed.

Unverified claims

Checked and fine

  • At 0462ef9, triangular_solve.rs:1131–1135 asserts ran_kib == 0; :579 increments staged-node count, not allocation count.
  • The base-to-head diff changes only the two Markdown files; git diff --check reports no errors.
  • Not run: Cargo tests, allocation measurements, or mutation tests; runtime and historical failure claims remain unverified.

Reviewed head: 0462ef9212dfbfaa1fb90315cf86a5f19d839fe9 at 2026-11-09T07:12:48Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

@shinaoka

shinaoka commented Nov 9, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 0
UNVERIFIED: 2

Critical (must not merge)

none

Needs changes

none

Unverified claims

  • CHANGELOG.md:20–21, PATCHSET.md:195 — The unchanged 468080 B allocation remains a reported measurement, not independently established evidence. PR perf(sparse): stop requesting the COLAMD workspace when the ordering is supplied (#322) #337 contains before/after output with that value, but this diff supplies neither a new measurement nor an allocation trace; the regression tests explicitly force simplicial analysis (faer/tests/sparse_symbolic_colamd_workspace.rs:75–82). Reproduce: run issue Sparse symbolic LU/QR with an explicit column ordering still allocate the COLAMD workspace #322’s counting program with --release against e756f13 and b989876, forcing supernodal LU and QR, and capture allocation backtraces. The four-array helper requests only 4 × 2000 × 8 = 64000 B; that calculation cannot identify the 468080 B allocation. The edited text acknowledges this limitation; I did not rerun the experiment.

  • PATCHSET.md:195 — “Both pass standalone at this revision” and the identical origin/main LQ failure lack revision-stamped evidence. /private/tmp/faer322-test2.log:1083–1086 records two unexpected allocations in full-pivoting LU at width 8, and faer322-test3.log:910–913 records ran_kib == 2 instead of zero, establishing the observed failures but not the standalone or baseline claims. Neither log identifies its commit. Reproduce: on the original pre-fix and post-fix revisions, record git rev-parse HEAD and the toolchain, then run cargo test -p t4a-faer -j6 --no-fail-fast, cargo test -p t4a-faer --test no_step_alloc, cargo test -p t4a-faer --lib staged_solve_is_bitwise_the_in_place_one -- --exact with the full test name, and cargo test -p t4a-faer --test lq_no_alloc. Cannot read a commit-stamped standalone/baseline artifact establishing those assertions; origin/main is also a moving reference.

Checked and fine

  • At 0462ef9212dfbfaa1fb90315cf86a5f19d839fe9, the supplied base-to-head diff changes only the two Markdown files, with 3 insertions and 2 deletions; git diff --check produces no diagnostics.
  • faer/src/linalg/triangular_solve.rs:1131–1135 requires zero staged nodes; stage::STAGED counts staging, not allocations. no_step_alloc defines its own process-local allocator counter.
  • Not checked: local builds, mutation tests, or allocation reproductions. At inspection, exact-head build and testing-stable-ubuntu-latest were still running; completed checks did not establish the historical runtime claims.

Reviewed head: 0462ef9212dfbfaa1fb90315cf86a5f19d839fe9 at 2026-11-09T07:17:22Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

@shinaoka
shinaoka merged commit b16d6b8 into main Nov 9, 2026
10 checks passed
@shinaoka
shinaoka deleted the docs/337-unverified-claims branch November 9, 2026 07:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant