Inplace matrix decompositions

Starting from Eigen 3.3, the LU, Cholesky, and QR decompositions can operate inplace, that is, directly within the given input matrix; the Hessenberg, tridiagonal, Schur, and QZ reductions and the dense eigensolvers followed. This feature is especially useful when dealing with huge matrices, and or when the available memory is very limited (embedded systems).

To this end, the respective decomposition class must be instantiated with a Ref<> matrix type, and the decomposition object must be constructed with the input matrix as argument. As an example, let us consider an inplace LU decomposition with partial pivoting.

Let's start with the basic inclusions, and declaration of a 2x2 matrix A:

code	output
Eigen::MatrixXd A(2, 2); A << 2, -1, 1, 3; std::cout << "Here is the input matrix A before decomposition:\n" << A << "\n";	Here is the input matrix A before decomposition: 2 -1 1 3

No surprise here! Then, let's declare our inplace LU object lu, and check the content of the matrix A:

Eigen::PartialPivLU<Eigen::Ref<Eigen::MatrixXd> > lu(A); std::cout << "Here is the input matrix A after decomposition:\n" << A << "\n";

Here is the input matrix A after decomposition: 2 -1 0.5 3.5

Here, the lu object computes and stores the L and U factors within the memory held by the matrix A. The coefficients of A have thus been destroyed during the factorization, and replaced by the L and U factors as one can verify:

std::cout << "Here is the matrix storing the L and U factors:\n" << lu.matrixLU() << "\n";

Here is the matrix storing the L and U factors: 2 -1 0.5 3.5

Then, one can use the lu object as usual, for instance to solve the Ax=b problem:

Eigen::MatrixXd A0(2, 2); A0 << 2, -1, 1, 3; Eigen::VectorXd b(2); b << 1, 2; Eigen::VectorXd x = lu.solve(b); std::cout << "Residual: " << (A0 * x - b).norm() << "\n";

Residual: 0

Here, since the content of the original matrix A has been lost, we had to declared a new matrix A0 to verify the result.

Since the memory is shared between A and lu, modifying the matrix A will make lu invalid. This can easily be verified by modifying the content of A and trying to solve the initial problem again:

A << 3, 4, -2, 1; x = lu.solve(b); std::cout << "Residual: " << (A0 * x - b).norm() << "\n";

Residual: 15.8114

Note that there is no shared pointer under the hood, it is the responsibility of the user to keep the input matrix A in life as long as lu is living.

If one wants to update the factorization with the modified A, one has to call the compute method as usual:

A0 = A; // save A lu.compute(A); x = lu.solve(b); std::cout << "Residual: " << (A0 * x - b).norm() << "\n";

Residual: 0

Note that calling compute does not change the memory which is referenced by the lu object. Therefore, if the compute method is called with another matrix A1 different than A, then the content of A1 won't be modified. This is still the content of A that will be used to store the L and U factors of the matrix A1. This can easily be verified as follows:

Eigen::MatrixXd A1(2, 2); A1 << 5, -2, 3, 4; lu.compute(A1); std::cout << "Here is the input matrix A1 after decomposition:\n" << A1 << "\n";

Here is the input matrix A1 after decomposition: 5 -2 3 4

The matrix A1 is unchanged, and one can thus solve A1*x=b, and directly check the residual without any copy of A1:

x = lu.solve(b); std::cout << "Residual: " << (A1 * x - b).norm() << "\n";

Residual: 2.48253e-16

Here is the list of matrix decompositions supporting this inplace mechanism:

• class LLT
• class LDLT
• class BunchKaufman
• class PartialPivLU
• class FullPivLU
• class HouseholderQR
• class ColPivHouseholderQR
• class RandColPivHouseholderQR
• class FullPivHouseholderQR
• class CompleteOrthogonalDecomposition
• class RandCompleteOrthogonalDecomposition
• class HessenbergDecomposition
• class Tridiagonalization
• class RealSchur
• class ComplexSchur (complex MatrixType only)
• class RealQZ
• class ComplexQZ
• class SelfAdjointEigenSolver
• class GeneralizedSelfAdjointEigenSolver
• class EigenSolver
• class ComplexEigenSolver (complex MatrixType only)
• class GeneralizedEigenSolver

The factorizations store their packed factors in the input matrix, as in the LU example above. For the reductions and eigensolvers, the input matrix is used as the workspace of the algorithm; what it holds afterwards depends on the class:

• HessenbergDecomposition and Tridiagonalization: the packed representation returned by packedMatrix().
• RealSchur, ComplexSchur, RealQZ, and ComplexQZ: the (quasi-)triangular factors T, or S and T; the unitary factors are stored in the decomposition object.
• SelfAdjointEigenSolver and GeneralizedSelfAdjointEigenSolver: the eigenvectors when they are requested, and eigenvectors() then refers to the input matrix; otherwise, unspecified values. The generalized solver also factorizes B in place.
• EigenSolver, ComplexEigenSolver, and GeneralizedEigenSolver: unspecified values; the results are stored in the decomposition object.

RealSchur may use a separate workspace even when instantiated with Ref<>. For an n-by-n matrix with n >= 128 and an outer stride in bytes divisible by 1024, it allocates a temporary padded matrix of n*(n+1) coefficients, performs the Hessenberg reduction and Schur iteration there, and copies T back to the bound input matrix. This also applies to compute(); computeFromHessenberg() uses the same padding policy for the Schur iteration. Zero inputs still incur the temporary allocation at these sizes and strides.

To avoid this temporary, bind a Ref<> with an outer stride in bytes that is not divisible by 1024. For example, a 512-by-512 double matrix can use a 513-by-512 column-major backing matrix and bind its top 512 rows; the outer stride is then 513*sizeof(double) bytes. Defining EIGEN_NO_MALLOC, or disabling allocation or deallocation through EIGEN_RUNTIME_NO_MALLOC, also suppresses padding and uses the bound storage, which may be slower. These controls do not eliminate other allocations: construction and resizing of solver storage, forming Schur vectors, or evaluating input expressions may still require memory. Inplace decomposition does not guarantee allocation-free construction or computation.

Since the decomposition object then refers to the input matrix, the input matrix must outlive it, as in the LU example. The QZ and generalized eigensolver classes take two matrices, and both must be passed as non-const lvalues to select the inplace constructor.