Sparse matrix factorizations (QR, LU, SVD, etc.)

[rcurtin]

Reported by rcurtin on 5 Jan 41873650 10:03 UTC
We should be able to factorize matrices the same way Armadillo already does it for dense matrices. However, we should depend on external solvers. According to James, GMM++ solvers for the QR, LU, or SVD factorization do not exist in GMM++, so we have to look elsewhere. I suppose, then, that the first part of this task is to find external solvers that we can use for the task.

Migrated-From: http://trac.research.cc.gatech.edu/fastlab/ticket/160

[rcurtin]

Commented by jcline3 on 23 Jun 41873728 16:09 UTC
After looking around a bit before going to sleep, I found 8 possibilities, but I need to look over the details a bit closer. I'm making a rather detailed list of features and what's missing, and possible issues for each one.

Is there anything aside from QR, LU, and SVD that we need? A few of the libraries I have found have some additional, possibly useful, algorithms. If it is just these three things that we care about, it may be reasonable to implement them ourselves. It's only a few hundred lines of code for all three with dense matrices, so it's probably not much more for sparse. (Admittedly, there are some slight issues that we would need to pay attention to, numerical stability, overflow and underflow...)

[rcurtin]

Commented by rcurtin on 25 Jan 41874643 09:53 UTC
I do want to mention that if there is a library that does everything GMM++ does plus also factorizations, we should switch to that entirely instead of using two dependencies.

[rcurtin]

Commented by jcline3 on 8 Nov 41877652 17:22 UTC
Going to try out cxsparse and arpack++; hopefully there will be no show stopping issues.

[rcurtin]

Commented by rcurtin on 2 Oct 41877844 13:37 UTC
Fix component

[rcurtin]

Commented by rcurtin on 17 Nov 41877847 00:05 UTC
I didn't mean to make myself the owner...

[rcurtin]

Commented by rcurtin on 13 Aug 41955774 04:32 UTC
Not entirely necessary for MLPACK 1.0, so I'm changing the milestone.

[rcurtin]

There's no reason to leave this issue open, and it isn't really within the scope of mlpack.