Abelian symmetric SVD #33
Conversation
|
Also note that I've added a function called |
|
@ogauthe I noticed that |
Co-authored-by: Lukas Devos <[email protected]>
src/factorizations.jl
Outdated
| ) | ||
| U = similar(A, axes(A, 1), dual(u_axis)) | ||
| T = real(eltype(A)) | ||
| S = BlockSparseMatrix{T,Diagonal{T,Vector{T}}}(undef, (u_axis, dual(v_axis))) |
There was a problem hiding this comment.
I noticed that this is not very general (for example it would be bad on GPU), probably it should be factored out into a similar_diagonal_blocks function or something like that.
There was a problem hiding this comment.
I agree, this is more or less why I had an original function _similar_S there to specialize on, since I don't think we really have the infrastructure right now to make that work.
The only thing I can come up with is trying to get type inference to tell us what the output type of initialize_output would be on the blocktypes of the input, but that also seems somewhat brittle.
There was a problem hiding this comment.
Yeah, it would be nice to come up with a good code pattern for this. I think promote_op on initialize_output of the input blocktypes could be a good general fallback definition, and then we could use similar(a, BlockType(...)) once we define that.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #33 +/- ##
==========================================
+ Coverage 94.09% 94.23% +0.14%
==========================================
Files 19 20 +1
Lines 711 763 +52
==========================================
+ Hits 669 719 +50
- Misses 42 44 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This PR preserves sector information when taking the SVD of an abelian GradedMatrix.
It makes use of the block sparse matrix SVD functionality added in ITensor/BlockSparseArrays.jl#111 and ITensor/BlockSparseArrays.jl#113, and depends on the additional customization points that are being added in ITensor/BlockSparseArrays.jl#114 (which isn't merged/registered yet, so tests are failing in this PR).
Closes #29.
@lkdvos @ogauthe
Note that non-abelian symmetries aren't accounted for here. We will have to change parts of the design to account for the kronecker product structure of the blocks which is being worked out by @ogauthe, I'm considering this to be a starting point and that can be considered in future PRs.
To do: