Skip to content

Conversation

@kshyatt
Copy link
Member

@kshyatt kshyatt commented Dec 2, 2025

This is needed to support the blocks of an AdjointTensorMap on GPU.

@kshyatt kshyatt requested a review from lkdvos December 2, 2025 18:04
Copy link
Member

@lkdvos lkdvos left a comment

Choose a reason for hiding this comment

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

Looks good to me, although I would have guessed that the ishermitian fallbacks automatically catch the non-<:StridedMatrix types?

@kshyatt
Copy link
Member Author

kshyatt commented Dec 2, 2025

Looks good to me, although I would have guessed that the ishermitian fallbacks automatically catch the non-<:StridedMatrix types?

Unfortunately not, at least not from my experiments :(

@lkdvos
Copy link
Member

lkdvos commented Dec 2, 2025

Any idea where that comes from? the strided_ishermitian_* implementations really are restricted to A::StridedMatrix, for example here:

ishermitian_exact(A::StridedMatrix; kwargs...) = strided_ishermitian_exact(A, Val(false); kwargs...)

while the default is the simple one:

ishermitian_exact(A) = A == A'

So I'm a bit confused how that fails?

@kshyatt
Copy link
Member Author

kshyatt commented Dec 2, 2025

Sorry, it's for the projection methods that we need this. I agree the fallbacks catch it for the is_ checkers.

@kshyatt kshyatt enabled auto-merge (squash) December 2, 2025 19:04
@codecov
Copy link

codecov bot commented Dec 2, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines Coverage Δ
...ixAlgebraKitAMDGPUExt/MatrixAlgebraKitAMDGPUExt.jl 87.30% <100.00%> (ø)
...MatrixAlgebraKitCUDAExt/MatrixAlgebraKitCUDAExt.jl 61.81% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@lkdvos
Copy link
Member

lkdvos commented Dec 3, 2025

These Mooncake tests are definitely taking quite some time, something we might actually have to worry about at some point?

@kshyatt
Copy link
Member Author

kshyatt commented Dec 3, 2025 via email

@lkdvos
Copy link
Member

lkdvos commented Dec 3, 2025

I guess this would make sense, after all the implementations don't depend on the different algorithms anyways. We can also just reduce the size of the arrays a bit, this shouldn't affect the validity of the tests and the finite differences should be faster.

@kshyatt
Copy link
Member Author

kshyatt commented Dec 3, 2025 via email

@kshyatt kshyatt merged commit f3de4de into main Dec 3, 2025
10 checks passed
@kshyatt kshyatt deleted the ksh/tk_again branch December 3, 2025 02:22
@Jutho
Copy link
Member

Jutho commented Dec 3, 2025

I guess this would make sense, after all the implementations don't depend on the different algorithms anyways. We can also just reduce the size of the arrays a bit, this shouldn't affect the validity of the tests and the finite differences should be faster.

Do you think the size of the arrays matter at this point? Ok, some of the tests might amount to computing the full Jacobian. So for a function such as svd, that maps order(N^2) elements to order(3 * N^2) elements, that is becoming a rather big Jacobian. Still, I would assume that for these AD tests most of the time is actually compilation time?

@lkdvos
Copy link
Member

lkdvos commented Dec 3, 2025

I didn't investigate actually, nor did I check what the current sizes are so I'm mostly just guessing. It felt possible that the finite differences can quickly blow up for large Jacobians, but you are definitely right that the compilation time might just dominate

@kshyatt
Copy link
Member Author

kshyatt commented Dec 5, 2025

Created #110 to address the mooncake issue

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.

4 participants