[eigen] Design for integrating different decomposition approaches |
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
Hi, 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. Regards, Hauke
Attachment:
DesignSample.zip
Description: Zip archive
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |