Skip to content
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

Allow uplo='F' for Symmetric and Hermitian wrappers? #1087

Open
amontoison opened this issue Aug 13, 2024 · 2 comments
Open

Allow uplo='F' for Symmetric and Hermitian wrappers? #1087

amontoison opened this issue Aug 13, 2024 · 2 comments

Comments

@amontoison
Copy link
Contributor

amontoison commented Aug 13, 2024

It could help to determine whether a symmetric or Hermitian sparse matrix wrapped in Symmetric or Hermitian contains both triangles or not ('F' = full).

With sparse matrices on GPUs, both triangles are always needed for the routines provided by NVIDIA / AMD / Intel, and this check could be useful.

@amontoison amontoison changed the title Allow uplo=:F for Symmetric and Hermitian wrappers? Allow uplo='F' for Symmetric and Hermitian wrappers? Aug 13, 2024
@jishnub
Copy link
Collaborator

jishnub commented Aug 14, 2024

I imagine one challenge with this implementation is that a lot of code has been written assuming that there are only two possibilities, and these would need to be updated to account for a third. Otherwise, I do see the merit in this.

@mikmoore
Copy link
Contributor

I worry about keeping the object valid under the :F mode. Sure, we could check it when it is wrapped, but if the parent is mutated asymmetrically then the object becomes invalid.

julia> x = [1 2; 2 3]
2×2 Matrix{Int64}:
 1  2
 2  3

julia> y = Hermitian(x, :U) # suppose we used :F here instead
2×2 Hermitian{Int64, Matrix{Int64}}:
 1  2
 2  3

julia> x[2] = 3; parent(y) # y would be silently invalidated if mode :F
2×2 Matrix{Int64}:
 1  2
 3  3

I think you'd get the same benefit from passing the matrix (with or without a wrapper) with a checkherm=false keyword to skip a ishermitian validation within the target function. That shifts responsibility for the validity of the object from the wrapper (who cannot hope to ensure its integrity short of the performance nonstarter of checking itself at every use) to the caller.

@KristofferC KristofferC transferred this issue from JuliaLang/julia Nov 26, 2024
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

No branches or pull requests

3 participants