general assessment and testing of linear algebra

[paciorek]

We have generally working linear algebra including sparse matrix operations.

I think the following are the main to-do items to wrap this up. Low technical risk but a lot of things to work on.

• assess operators provided for sparseMatrix (not sparse cholesky factor) LHS arguments for various linear algebra operators
• check completeness of testing for non-sparse matrix cases
• deal with bug/lack of handling for RHS vectors (not matrices) for various operators - I think there is some basic bug in our LAT handling
• check handling of RHS sparseVector and sparseMatrix args
• add functionality for dense Cholesky factors analogous to sparse Cholesky (and possibly with some additional operators such as nDiag); need to determine the extent to which this is just handling L or U matrix as explicit matrix
• check error-trapping of Transpose, diag and other such non-handed operators applied to cholesky factor objects
• generally error trap (and add tests) for input types to lin alg operators. E.g., nLogdet has an untrapped error if the input is numericVector. The C++ error message is pretty clear that there is 'no matching function', but we want to catch this in our processing.
• check passing sparseCholFactor object around in R and back into nFunctions; error trap as needed
• nSolve(sparseMat) should be error-trapped in nCompiler compilation as no LU capability; also generally error trap uncompiled/compiled attempts to pass sparse/non-sparse chol factor into non-supporting lin alg operators
• check what happens with x %*% y for x a cholesky factor object; it's hard for us to overload this in R since x will be a Matrix type, so we may have distinct uncompiled/compiled behavior
• check Josh' current lin alg and sparsity tests and notes about failure of sparse+sparse
• in general set up complete testing for all general matrix, sparse matrix, dense and sparse Cholesky factors with dense or sparse RHS args
• be careful to include testing of expressions given Eigen's use of unevaluated code, e.g., solve(A+B,c)
• consider using nMult (see torch/tensorflow naming) and nSVD (capitalized)
• it might be good to have a basic example/"test" of using a sparse SPDE-based matrix in a basic spatial model for HMC/Laplace/nested approx