Possibility of QR decomposition

[juliagpu]

Possibility of QR decomposition

[vchuravy]

The other option would be to implement QR decomposition ourselves (there are some fun research papers on that topic.)

[MikeInnes]

If it's in CUBLAS then it should be pretty easy to wrap (I don't know if it is though).

If not there may be a third-party library we can borrow; or it may not be too difficult to write a custom kernel to do it.

[MikeInnes]

Ok, these are actually a part of cuSOLVER. We have wrappers for that here, but they are pretty stale.

It would be very useful to update CUSOLVER.jl, and perhaps move the wrappers into CuArrays as we did with CUBLAS.

[jdnz]

Hi Mike,
Thanks for integrating cuSolver into this package. I was looking at it and trying to also add the function orgqr that takes the output from geqrf and returns the Q matrix from the QR decomposition (see #36). This works fine when the matrix A from qeqrf has size(A, 2) < size(A, 1), but in the reverse case we need to slice the matrix Q = A[:, 1:size(A, 1)]. This gives an error when you have CuArrays.allowscalar(false) as you do in the test file. Does that mean that such a slice is suboptimal? Is there some other way to do it? This also applies to making the ormqr code more general, i.e. to work when size(A, 2) != size(A, 1).

[MikeInnes]

Slicing like that should be fine – it works with xs = cu(rand(5,5)); xs[:, 1:5] for example. Is that definitely what's causing the issue?

[jdnz]

Ah yeah sorry, I just realized it was caused by an actual scalar index call. I've replaced it now, so it should work correctly.

[andreasnoack]

I think this can be closed