Linear algebra test coverage for SubArray

[andreasnoack]

Below is the list of linear algebra test files that we'll need to extend with SubArray tests. Please update the list if SubArrays are already covered (systematically) for the file

• arnoldi.jl
• bidiag.jl
• bunchkaufman.jl
• cholesky.jl
• dense.jl
• diagonal.jl
• eigen.jl
• generic.jl (see Adding SubArray tests to generic.jl, includes fix for linreg bug found julia#15145)
• givens.jl
• lapack.jl
• lu.jl
• lq.jl
• matmul.jl
• pinv.jl
• qr.jl
• schur.jl
• special.jl
• svd.jl
• symmetric.jl
• triangular.jl
• tridiag.jl
• uniformscaling.jl (see Test UniformScaling methods with SubArrays. julia#14731)

[andreasnoack]

@kshyatt Are tridiagonal, bidiagonal and diagonal now covered? If so, please update the list.

[pkofod]

just to be 100% sure, this is simply to make sure that the functions return the same thing / work even if it's a SubArray and not an array?

[kshyatt]

Yeah, the idea is to make sure Diagonal {*, +, -, /} SubArray still works.

[pkofod]

svd.jl should be covered by JuliaLang/julia#15314 .

[andreasnoack]

Great. Top post is now updated.

[pkofod]

I'll probably grab some more the coming days, and pile them in a PR with separate commits. I assume none are taken?

[tkelman]

Nope, go nuts. Keep em coming @pkofod, big fan of your recent contributions.

[pkofod]

Most of arnoldi.jl is sparse matrices. Should these just be ignored here? Methods don't seem to be defined for sparse matrices (#15355 ) possibly because it will rarely be a good idea to operate on views of sparse matrices.

[tkelman]

I don't think this is intentional, it's just that few if any methods for working with views of sparse matrices have been written yet.

[pkofod]

As pointed out by Tim Holy at JuliaLang/julia#15354, it works in JuliaLang/julia#15367

[tkelman]

Though if it's dispatching to a generic fallback, it's likely quite slow and not taking advantage of sparsity, so optimized methods do still need to be written to get decent performance.

[pkofod]

Yes I realize that, I was only thinking about: "does it work?". If it is expected to work, I figured it should be tested. Even if it would probably be stupid for most users to do it currently.

[pkofod]

Regarding this issue... Is it "acceptable" to continue down this road right now, or will a PR that increases test times not be merged anyway? (I'm thinking about the whole CI discussion...) Also, I think there are some completed files that are not ticked off (matmul, eigen, schur, bunchkaufman).

[andreasnoack]

I don't think we should hold back on adding tests here but @tkelman can tell if we are too close to the limit. Recently, the triangular tests got faster after avoiding many calls to generic_matmatmul! so maybe there is some extra room. It might be possible to further reduce the number of times generic_matmatmul! is compiled or reorganize that function to become cheaper to compile.

[tkelman]

The time per CI run has gotten about 20 minutes faster over the last few months, which is great work by the compiler gurus. But we are having more frequent freezes and it's generally busy with a lot of builds per day adding up to a usually-long queue.

[kshyatt]

I think lq.jl is actually covered? Since I pulled those tests from qr.jl it may be as well. See here.

[ViralBShah]

@kshyatt Are we now in a good enough place, that we can close this?