Re: [eigen] Design for integrating different decomposition approaches |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Design for integrating different decomposition approaches*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Tue, 12 May 2009 21:53:11 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=mKh97pPg6dO6bN2D+JyWBiPJqmnmPo0tOitzpi3tf18=; b=BX1ShHG0wTx8bVJe7u3zijFBZj7tdR9wWjxM5X8AI0axq9JYO1GzWCbqcCPOJUur6U K7Bcn2iO178llz/5zbZTAlF7mTMgKgQGo6ydlap5gk/oZpRdXUn364LrpN6YcVp5Qoh/ CuVxbQ0aPcLH9XvwhsWrjD0x9HsS3qVov06ow=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=aUj6RZuxzT1SGNsKNE2S+kL1kUlGX/HpGDPb/YX/oNHZ2pXNDjUmzH64G4gaQmImxX 4Arl+3XqpM3MpgE98BUdUZGXUqdU5C/9PEr7nepiFKvgqo8RdNji7Vlb05CtKX/x9C80 Riok25xfdCseoY1o0wGi/s12zTclLuYTShJTE=

Hi, Thanks for your ideas, 2009/5/12, Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>: > 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? Yep, so indeed, at least at the level of implementation, LU and partial-pivoting-LU are two separate classes. > 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; This isn't more concise than: PartialPivotingLU<MatrixXf> lu_partial; and we haven't even considered the case where we're outside of namespace Eigen and thus you'd need Eigen:: twice. Actually I was considering naming the partial pivoting LU just "FastLU", what's your opinion? The idea is that it's faster but assumes you know what you are doing (it's only valid, basically, for invertible square matrices, as I wasn't going to bother about the rectangular case here which will only work either for m>=n or m<=n but not both). I'm also a bit reluctant about us taking the habit of exposing algorithm names as part of the API. Here it makes sense because they are really different decompositions with different APIs but in other cases, if the APIs are identical, better keep the choice of algorithm a private thing so we're free to switch to a better algorithm in the future. > 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. I'm not sure about this one: to me, it kind of suggests that LU<> is the same class in both cases, hence in particular offers the same API, which isn't going to be the case (partialpivoting won't have rank() for example). Cheers, Benoit

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

**Re: [eigen] Design for integrating different decomposition approaches***From:*Hauke Heibel

**References**:**[eigen] Design for integrating different decomposition approaches***From:*Hauke Heibel

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

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