[eigen] Design for integrating different decomposition approaches

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


I was pondering a bit about the recent discussions regarding different
algorithms for matrix decompositions. Recently, we have seen that
there are different use cases for different kinds of decompositions.

Let's for example consider the LU decomposition - if I remember
correctly there was a discussion on partial pivoting vs. full pivoting
and at some point Benoit offered to take a look/implement the partial
pivoting. Let us assume now this were about to happen. What would
Benoit (or any other contributor) do now? Well, there are many
options. You could simply add a method in which you chose the type of
pivoting. This is probably not the best way to do it since the LU
interface might change or become invalid depending on the underlying
algorithm. What do you want for instance with two permutation
matrices, when only partial pivoting is performed? Let's now assume we
introduce a new class, e.g. PartialPivotingLU. This is definitely
possible and besides the clumsy class name a valid and nice solution.
The interface could be adapted and everything is fine but maybe there
is another way....

What if you could write

LU<MatrixXf> lu_full;

and have the well known Eigen interface of the LU decomposition
available but on top you could write as well

LU<MatrixXf, Algorithms::PartialPivoting> lu_partial;

and have a LU decomposition that this time does only partial pivoting
while adapting the interface.

Both cases were using the same concise naming and it were clear to the
user that both times she/he were dealing with an LU decomposition
while offering the correct interface. This can be achieved by using
verneers (synesis.com.au/resources/articles/cpp/veneers.pdf) or mixins
which is in the end nothing but letting the base class LU derive from
a particular implementation of the decomposition. In this example it
is Algorithms::PartialPivoting or Algorithms::FullPivoting (default
template parameter). If you are interested you may take a look at the
attached code.

I am just wondering and curious about your remarks.


Attachment: DesignSample.zip
Description: Zip archive

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/