matrix_type strangulation strategy

[pinkwah]

matrix_type to Eigen

Eigen is a C++ linear algebra package that allows us to write readable maths that is compiled into fairly efficient executable code.

At the moment, we use a home-grown solution called matrix_type. This provides some basic arithmetic and some slightly more advanced functionality via the BLAS and LAPACK libraries. matrix_type's memory layout is similar to that of Eigen dense matrices (and probably all other dense matrix implementations in the known universe).

While there are a lot of similarities between the two APIs, having matrix_type be backed by an Eigen::MatrixXd (arbitrary dimension dense matrix of type double), it would require a single PR that replaces the entirety of the 2000+ line implementation that we have today, while providing little benefit. Most of Eigen's magic comes from its use of temporary objects. Eg, in Eigen, matrix.transpose() returns a type Eigen::Transpose<MatrixType> which is an ephemeral (prvalue in C++ terminology) and can be used together with other expressions to force the compiler to optimise the code properly. Because matrix_type's API works on whole matrix_types, no such optimisations can take place in user code.

Since Eigen::MatrixXd types have a very similar layout to matrix_type today, another strangulation strategy would be to replace matrix_type's internals with a single Eigen::MatrixXd object and have some logic to have a matrix_type-like view into the Eigen object. Functions that haven't been ported yet may rely on this compatibility view to perform their job as before. However, manipulating an object whose code-base we don't own would make us prone to errors.

The approach that I think is the most defensible is creating a new class ert::MatrixXd which will be a subset of Eigen::MatrixXd's API, but be a thin wrapper around matrix_type. This will allow us to start iteratively implementing an Eigen-like API. The hope is that at some point in the future we'll simply be able to s/ert::MatrixXd/Eigen::MatrixXd/ and remove the legacy code.

Actionable steps

1. Clean up unused matrix functionality (det4, det3, det2)
2. Move functionality only used in matrix tests into the test code
3. Create a simple ert::MatrixXd with a nicer initialising ctor, arithmetic operators and a std::unique_ptr-like object management API (ie: .get() -> matrix_type*, .release() -> matrix_type*, .reset(matrix_type*))