[eigen] Design for integrating different decomposition approaches |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: [eigen] Design for integrating different decomposition approaches*From*: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>*Date*: Tue, 12 May 2009 21:14:51 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Njocye/NyaazD1Go9+I4mWSaFToiuBi3W0pT7EM4Qdc=; b=NNKmcOSmiJwpj2WKbZr1sACYVR1LbP49F9Zq362gDLkUPzGe0Xz6pYCUj3asHTQa8a 5Y6SFHaJ63MgOHqWqvO2L/V/z6FhEevNUoiy2yNomD3k/9RCbymvu9hcUhGA+DH95Tpu 0CR5RT4Aisye35UNAzIsRyV6joywxMWIU5WmE=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iP0qF2B/uHa4av/ixCiMJAI7OIF0GMvhpLXhVmoLmXyXn1RoonEhHuTD1EKuol8vMq LMi8T7MpCHZcb7Vra/+EHUhcf/XUoPj5EXmBXU1IidL3XOdDlYgoDXvHHt/qSADDEmO2 9RIz0xqBXZQj5B7tV+pXKoeA/6x+6VfW0djIE=

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**

**Follow-Ups**:**Re: [eigen] Design for integrating different decomposition approaches***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Migration to mercurial : final tests** - Next by Date:
**Re: [eigen] Migration to mercurial : final tests** - Previous by thread:
**Re: [eigen] Migration to mercurial : final tests** - Next by thread:
**Re: [eigen] Design for integrating different decomposition approaches**

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