Add support for eigvals
, svdvals
and diag
, diagm
.
#130
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 PR extends some of the LinearAlgebra functions for obtaining information about diagonal entries. This is particularly useful as it allows the definition of rrules for
eigvals
andsvdvals
, which would otherwise necessarily involve accessing tensormap data, an operation that typically breaks Zygote.The implementation currently returns
Vector
objects for TrivialTensorMap's, andSectorDict{I,Vector}
objects in all other cases. I agree that this would be more elegantly solved with something likeDiagonalTensorMap
, but as this is not (yet) implemented and requires a bit more effort, this could work as an intermediate solution.Note however that this does introduce a subtlety when dealing with non-abelian symmetries, as this yields an intermediate representation where people will have to keep in mind that the inner product is non-trivial.
See the finitedifferences implementation in test/ad.jl#L50 for the consequence.
I did not add any docstrings to these methods, as this really does form a valid implementation of the original functions (which thus already have docstrings), but I could of course add them if needed.
Finally, I choose to not include
eigvecs
into this PR, as the implementation of theeig
functions and the respective gauge choices should be re-evaluated, which I think is beyond the scope of this PR, and thus the implementation would really boil down toeigvecs(t) = eig(t)[2]
, which does not really yield large benefits at the moment.