Skip to content

[WIP] MatrixAlgebraKit decompositions #230

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 47 commits into
base: master
Choose a base branch
from
Draft

[WIP] MatrixAlgebraKit decompositions #230

wants to merge 47 commits into from

Conversation

lkdvos
Copy link
Collaborator

@lkdvos lkdvos commented Mar 16, 2025

This PR is part of a large set of changes that alters the backend from TensorKit.MatrixAlgebra to MatrixAlgebraKit for the factorizations.
Concretely, this is achieved through a new submodule TensorKit.Factorizations that implements most of the MatrixAlgebraKit interface, along with some overloads and reimplementations to be somewhat backwards compatible.

New features

  • foreachblock(f, t::AbstractTensorMap...) is a new function that is meant to provide a uniform interface to iterate through the blocks of a collection of tensors. The main purpose is to centralize this concept to easily add multithreading over the blocks. In order to break up this PR the actual multithreading implementation is left for a follow-up PR.
  • eig, eigh and eigen now have preliminary support for a truncated version of these algorithms.
  • The factorizations can now swap out their backends to select alternate algorithms or implementations.
  • ominus and its unicode variant can now be used to obtain the orthogonal complement of a space, ie if W = oplus(V1, V2), V2 = ominus(W, V1).

Breaking changes

  • The tsvd function no longer outputs the truncation error, and instead just gives U, S, Vh.
  • The truncation strategies are now directly inherited from MatrixAlgebraKit. This means truncdim is replaced by truncrank, trunctol is replaced by truncbelow, and there are deprecation warnings for the old functions.
  • The leftorth and rightorth functions will now always output tensors with a single space connecting them, which was not the case for Polar decompositions previously. To retrieve the old behavior with isposdef R factors (equal domain and codomain instead of isomorphic), new functions leftpolar and rightpolar are added.
  • The leftorth and rightorth functions will now always have a connecting space with isdual=false. This is different from the previous behavior where some N,1 or 1,N tensors kept the isdual flag on the connecting leg.

@lkdvos lkdvos requested a review from Jutho March 16, 2025 20:19
@lkdvos lkdvos marked this pull request as draft March 16, 2025 20:19
Copy link

codecov bot commented Mar 16, 2025

Codecov Report

Attention: Patch coverage is 64.34109% with 46 lines in your changes missing coverage. Please review.

Project coverage is 73.28%. Comparing base (daf2f53) to head (40d12d8).

Files with missing lines Patch % Lines
src/tensors/matrixalgebrakit.jl 67.61% 34 Missing ⚠️
src/tensors/backends.jl 25.00% 6 Missing ⚠️
src/tensors/diagonal.jl 0.00% 6 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (daf2f53) and HEAD (40d12d8). Click for more details.

HEAD has 4 uploads less than BASE
Flag BASE (daf2f53) HEAD (40d12d8)
6 2
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #230      +/-   ##
==========================================
- Coverage   82.63%   73.28%   -9.35%     
==========================================
  Files          43       45       +2     
  Lines        5557     5649      +92     
==========================================
- Hits         4592     4140     -452     
- Misses        965     1509     +544     

☔ View full report in Codecov by Sentry.
📢 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.

@lkdvos
Copy link
Collaborator Author

lkdvos commented Jun 12, 2025

The test failures on empty tensors should be resolved once QuantumKitHub/MatrixAlgebraKit.jl#37 is merged.

@Jutho I think this is ready for another round of review, it definitely requires a bunch more cleanup but I think I am getting somewhere now, the improvements in MatrixAlgebraKit have definitely helped a bunch.
I'm struggling quite a bit with figuring out how breaking of a change I would be okay with, but making sure all old algorithms and syntaxes still work is turning out to be a major pain.
I'm not so sure if it is even worth it to keep QR, SVD, ... around, and while I could make them type aliases for their MatrixAlgebraKit counterparts in the meantime, this doesn't work for QRpos. I am leaning towards just doing that though, since it would definitely simplify more code.

@@ -265,6 +275,21 @@ function LinearAlgebra.mul!(dC::DiagonalTensorMap,
return dC
end

function LinearAlgebra.lmul!(D::DiagonalTensorMap, t::AbstractTensorMap)
domain(D) == codomain(t) || throw(SpaceMismatch())
for (c, b) in blocks(t)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we immediately want to write this using foreachblock?

end
function LinearAlgebra.rmul!(t::AbstractTensorMap, D::DiagonalTensorMap)
codomain(D) == domain(t) || throw(SpaceMismatch())
for (c, b) in blocks(t)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment/question.

return isposdef!(tcopy)
end
function LinearAlgebra.isposdef(t::AbstractTensorMap)
tcopy = copy_oftype(t, float(scalartype(t)))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the second argument also be factorisation_scalartype(isposdef, t)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to ask this still: do you think it is reasonable to just adopt isposdef in the list above, and actually define it both for isposdef(t, p) and isposdef?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went ahead and implemented this as such, if you disagree I'm happy to change it back.

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.

2 participants