Skip to content

Operand-driven diagonal algebra for the dense path - #224

Merged
mtfishman merged 16 commits into
mainfrom
mf/diagonal-algebra
Aug 21, 2026
Merged

Operand-driven diagonal algebra for the dense path#224
mtfishman merged 16 commits into
mainfrom
mf/diagonal-algebra

Conversation

@mtfishman

@mtfishman mtfishman commented Aug 20, 2026

Copy link
Copy Markdown
Member

Summary

Make diagonal algebra operand-driven: Diagonal is kept when the result is genuinely diagonal and densified otherwise. Also renames [co]domain_axes to axes_[co]domain. Companion to ITensor/GradedArrays.jl#264.

Preserve the Diagonal type through the operations whose result is genuinely diagonal: factorizations return the spectrum bare, unmatricize keeps the (1,1) endomorphism split, and single-contracted-leg Diagonal times Diagonal stays Diagonal. Densify only where the result is not representable as a Diagonal.
@codecov

codecov Bot commented Aug 20, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 88.17204% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.09%. Comparing base (4360ee3) to head (3b6920a).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
src/projectto.jl 82.60% 4 Missing ⚠️
src/similar_map.jl 84.21% 3 Missing ⚠️
ext/TensorAlgebraTensorKitExt.jl 86.66% 2 Missing ⚠️
src/matricize.jl 87.50% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #224      +/-   ##
==========================================
+ Coverage   80.05%   80.09%   +0.03%     
==========================================
  Files          28       28              
  Lines        1038     1050      +12     
==========================================
+ Hits          831      841      +10     
- Misses        207      209       +2     
Flag Coverage Δ
docs 22.29% <19.56%> (+0.40%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

The dense `unmatricize` reshaped without validating the split, so a mismatched codomain/domain boundary with the right total element count would reshape silently. Add a `check_input` size guard, matching the `Diagonal` and graded paths.
Replaces a runtime length branch in the two-`Diagonal` `contract` output allocation with dispatch on the perm tuples, matching the operand-driven convention. Also drops the `Diagonal`-specific `unmatricize` `check_input`, whose general-looking signature only admitted the `{1,1}` split, in favor of the generic size check.
A dense `unmatricize` is a `reshape`, so it only needs the total element count to match, not the per-side codomain/domain split. The earlier per-side check rejected valid regroupings such as `unmatricize(m, (), axes)`.
`promote_type` returns the plain element type, but a product accumulation can widen (for example `Bool` inputs accumulate to `Int`), so model it with `Base.promote_op(matprod, ...)` as matmul does.
The helper is only ever called with `Diagonal` operands and reads `a1.diag`, so annotate `a1::Diagonal` to make that explicit.
The output type is a function of both operands, so take `a1::Diagonal, a2::Diagonal` even though the allocation reads only the first.
Re-opens 0.20.0 as a prerelease accumulator (its standalone registration was removed), so these changes ship in a single 0.20.0 release rather than a separate patch.
The matricized input's rows must be the fused codomain and its columns the fused domain, matching what `matricize` produces, so a matrix with the right element count but the wrong split is rejected instead of reshaped silently.
Mechanical rename matching the `axes_codomain`/`axes_domain` naming used across the ecosystem.
The standalone 0.20.0 registration was pulled, so this ships as the 0.20.0 release (registered manually, since the version matches main).
@mtfishman mtfishman changed the title [WIP] Operand-driven diagonal algebra for the dense path Operand-driven diagonal algebra for the dense path Aug 21, 2026
@mtfishman
mtfishman marked this pull request as ready for review August 21, 2026 01:09
The generic `allocate_output` computes the checks, output axes, and element type once and delegates the container choice to an internal `allocate_contract_output`, deduplicating the `Diagonal` path. `output_axes` now returns construction-convention domain axes.
…check

The Diagonal contract output now takes the codomain axis itself rather than its length, so a structured `diag` vector keeps its axes, and `unmatricize` rejects non-matrix inputs.
The 0.20 line accumulates further breaking changes on main and releases later as a single 0.20.0.
@mtfishman
mtfishman merged commit 0fc4b31 into main Aug 21, 2026
16 of 17 checks passed
@mtfishman
mtfishman deleted the mf/diagonal-algebra branch August 21, 2026 16:51
mtfishman added a commit to ITensor/GradedArrays.jl that referenced this pull request Aug 21, 2026
## Summary

Make diagonal algebra operand-driven on the graded path: keep a
`FusedGradedDiagonal` when the result is diagonal, densify otherwise.
Companion to ITensor/TensorAlgebra.jl#224.
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