Route TensorMap in-place linear algebra through VectorInterface#207
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #207 +/- ##
==========================================
- Coverage 81.03% 80.65% -0.38%
==========================================
Files 24 24
Lines 907 910 +3
==========================================
- Hits 735 734 -1
- Misses 172 176 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
mtfishman
force-pushed
the
mf/tensormap-inplace-ops
branch
from
62de6fb to
fa6eea7
Compare
mtfishman
added a commit
to ITensor/ITensorBase.jl
that referenced
this pull request
Jul 11, 2026
…ods (#217) ## Summary Implements the full `VectorInterface` for named tensors and routes its in-place operations through name-aware `TensorAlgebra` methods instead of self-aliasing broadcasts. `scale!`/`add!` forward to `TensorAlgebra.scale!`/`TensorAlgebra.add!`, which unname and align the operands by name (reusing the `unnamed(x, dimnames(y))` view, which carries a tuple permutation) before dispatching to the backend array's block-wise in-place method. This fixes silent corruption when a block-sparse backend drives an iterative solver: the previous `@. y = y*β + x*α` put the destination on the right-hand side, and a graded `copyto!` ran the `y*β` term as a self-aliased permute-add that zeroed `y` before reading it. The out-of-place and `!!` variants allocate the promoted scalar type, so scaling a real tensor by a complex coefficient widens to a complex result. `inner` forwards to `LinearAlgebra.dot` (previously a duplicate of the same `(conj(x)*y)[]`), and `_permuteddims_to` drops its `AbstractArray` restriction so the by-name alignment view also works for a `TensorMap` backend. The methods are defined as qualified `VectorInterface.` overloads, so ITensorBase no longer imports the `VectorInterface` function names into its namespace or re-exports them. Builds on ITensor/TensorAlgebra.jl#207, which adds the `TensorMap` `TensorAlgebra.scale!`/`add!`/`zero!` methods this forwarding lands on.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Defines
TensorAlgebra.zero!,scale!, andadd!forAbstractTensorMapas thin forwards to the correspondingVectorInterfacemethods, which are TensorKit's primary interface for these in-place linear operations. The genericAbstractArraydefinitions don't apply, since aTensorMapis not anAbstractArray, and routing throughVectorInterfacekeeps a self-aliased call such asa .*= 2oradd!(a, a, α, β)a correct block-wise rescale instead of aliasing the destination with an operand through a broadcast. Theadd!method here is the non-permutingy = α*x + β*y. The permutingbipermutedimsopadd!still fuses a non-trivial codomain/domain permutation for the matricize, contract, and broadcast callers.VectorInterfacebecomes a weak dependency on the TensorKit extension's trigger list. It is already a dependency of TensorKit, so loading TensorKit pulls it in and the effective load trigger is unchanged.