Death to BraidingTensor#444
Draft
lkdvos wants to merge 9 commits into
Draft
Conversation
Codecov Report❌ Patch coverage is
... and 60 files with indirect coverage changes 🚀 New features to boost your workflow:
|
Drive JordanMPOTensor off a single full-space `tensors` SparseBlockTensorMap plus a `scalars` Dict of identity coefficients, instead of the four reduced-leg A/B/C/D fields. The four-block decomposition is preserved as derived `getproperty` accessors (with a 5-arg constructor that writes back), so existing consumers keep working. Generic `getindex` materializes scalar entries as `TensorMap`s; the `.A` accessor preserves `BraidingTensor`s for hot kernels. Drop the now-redundant `JordanMPOTensorMap` alias and its export. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- MPOHamiltonian getproperty `:A` delegates to the tensor-level accessor so identity levels stay `BraidingTensor`s (keeps `isidentitylevel` correct). - Rewrite `scale!` to act directly on `tensors`/`scalars` (the `.A/.B/.C/.D` accessors share data via `removeunit`, so in-place scaling of a copy leaked into the source). - Add a 2-field `JordanMPOTensor(tensors, scalars)` constructor and use it in the Adapt extension and the `force_planar` test helper. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- 5-arg constructor: insert the trivial boundary legs with the duality dictated by V (via isdual of the corner space), so conjugated MPOs (_conj_mpo) embed correctly instead of hitting a SpaceMismatch. - Adapt extension: convert the `scalars` coefficients to the adapted scalartype so precision changes (e.g. ComplexF64 -> ComplexF32) construct cleanly. - Replace internal `getfield(W, :tensors/:scalars)` with `W.tensors`/`W.scalars` (the getproperty passthrough), keeping only the one passthrough getfield. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The A/B/C/D blocks are computed properties that rebuild a fresh SparseBlockTensorMap on every access. Avoid redundant reconstruction: - jordanmpotensor: rewrite `_jordan_B`/`_jordan_C` and `nonzero_values`/ `nonzero_pairs` to iterate `tensors`/`scalars` directly instead of `nonzero_keys(W)` + `W[I]`; add `_identity_tensor` helper. - hamiltonian_derivatives: bind `W.A/.B/.C/.D` once in the AC and AC2 derivative builders (W*.A was rebuilt ~8x per AC2 build). - ortho: cache blocks in left/right_canonicalize! and drop `typeof(W.A)`-style reconstructions. - mpohamiltonian: answer `isidentitylevel` from `scalars` instead of reconstructing every site's A block. Also expand the JordanMPOTensor docstring. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…x{4}
- SparseBlockTensorMap(::JordanMPOTensor) now produces a uniform concrete
`TensorMap` block type with the identity scalars folded in, instead of an
abstract eltype carrying BraidingTensors.
- Store `scalars` as `Dict{CartesianIndex{4},T}` keyed by the full
`(row, 1, 1, col)` virtual position, matching `tensors`; update getindex,
setindex!, haskey, the nonzero_* iterators, the block accessors, scale!,
isidentitylevel and the Adapt extension accordingly.
- `_identity_tensor` now takes the CartesianIndex{4} position directly.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The corner assertion now accepts entries that are approximately identity braidings (not only literal `BraidingTensor`s), via the `_isbraiding` helper. The corners are then folded back into scalar identities by the constructor, so `JordanMPOTensor(SparseBlockTensorMap(W))` round-trips even after the converter densifies identities into `TensorMap`s. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- `_jordan_A` now returns a concrete `SparseBlockTensorMap{TensorMap}` with the
identity scalars folded in, instead of `Union{TA,BraidingTensor}` carrying
BraidingTensors. All four block accessors now share the same TensorMap eltype.
- getindex/setindex! are now written on `CartesianIndex{4}` as the primary form;
the `Vararg{Int,4}` and linear-index methods delegate to it.
- setindex! accepts a `Number` or a `BraidingTensor`, both of which are stored as
a scalar identity entry (the number as its coefficient, the braiding as one);
any other tensor is stored in `tensors`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
This is a (WIP) implementation that redesigns the
JordanMPOTensorinterface, instead of keeping theBraidingTensorsexplicitly in the block tensor, which causes a lot of promotion issues, to keep them separate in a "scalars" field.Right now, we aren't really using the scalars for anything other than detecting where the identity tensors are on the diagonal, so we can properly renormalize variances etc. I'm not sure if this ever really factors into the computations, and in any case with the altered contraction orders for the derivatives this never matters anymore, since we always contract the braiding tensors on one leg only (with the environments instead of with the environment + mps).
@kshyatt I'm not sure if there is a way to check if/how many issues this solves?