> The algorithm used there produces the matrix R and an array of > Householder vectors. When the getQ() is called, the Householder > vectors are made into matrices that are multiplied together to yield > the Q matrix. This seems to be the best way to go about things. > That seems fine to me, in terms of the state maintained in the decomp class and the API as well - i.e., provide the accessors for Q and R, but maintain state efficiently.
Done; this is what QRDecompositionImpl does now. Singular and rectangular cases are covered. The tests are more extensive, too. http://issues.apache.org/jira/browse/MATH-148 There is one thing I'm not sure about: matrix dimensions. Some sources define the QR-factorization of an m x n matrix so that Q is m x m (square) and R is m x n, others say that Q is m x n and R is n x n (square). The current implementation does the former. Of course it's also possible to define Q as m x r and R as r x n, where r is min{m, n} or the rank of the original matrix. Do you have any insights on what should be done?
> I suppose we won't have a base interface for matrix decompositions? We can talk about that, but if we go with the design above, there is really no place for it, unless I am missing something. Now is a good time to discuss these things, though, as once we define the API, we (and our users) are going to have to live with it for some time. Other than a "decompose" method (which the design above does not include), its hard for me to see what a base decomposition interface would include. The accessors are all different depending on the decomp. Could be I am missing something, though, so if you have ideas about how to better structure this, please speak up.
It seems that many decompositions are used for solving linear systems. A decomposition object "knows" what the system is like and has access to the raw factorized data that can be packed in some way, so it would make some sense to ask it solve systems, too. Plus: users would be able to switch between different implementations, like with the Collections API. Then again, solving systems doesn't seem like something inherent to the idea of a matrix factorization. Could it be a better idea to have an interface like "LinearSystemSolver" which then can be implemented by decomposition classes?
