[eigen] In-place decompositions; was: UmfPackSupport vs SuperLUSupport: input matrix |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: [eigen] In-place decompositions; was: UmfPackSupport vs SuperLUSupport: input matrix*From*: Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>*Date*: Tue, 16 Apr 2013 15:49:21 +0200

On 16.04.2013 15:21, Gael Guennebaud wrote:

Yes I know, but it looked complicated to do so with our current design. Actually, for a very long time now, I've the idea to make our decomposition classes behave even more like a matrix, but with a factorized storage. With that in mind, the .compute() method would become an alias for operator=(). dec.solve(b) would be an alias for dec.inverse() * b thus allowing for: b * dec.transpose().inverse() without relying on weird option: ApplyTransposeOnTheLeft...

So this just gave me the idea that we could imagine doing: dec.swap(A); If A is compatible enough with dec, we could simply exchange pointers. An alternative would be to add a "grab" function: dec.grab(A) dec would "grab" the memory available in A, make A an empty object, and then perform the factorization.

On Tue, Apr 16, 2013 at 2:51 PM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:On 16.04.2013 14:43, Gael Guennebaud wrote:this is because the matrix coefficients are modified by SuperLU itself, so we have to make a copy to preserve the user data.Actually, it would be nice sometimes to have methods which store the decomposition over the input data (where applicable). This could come handy for dense decompositions as well if the original matrix is not required anymore (saving memory and a copy operation). Christoph

-- ---------------------------------------------- Dipl.-Inf., Dipl.-Math. Christoph Hertzberg Cartesium 0.049 Universität Bremen Enrique-Schmidt-Straße 5 28359 Bremen Tel: +49 (421) 218-64252 ----------------------------------------------

**Follow-Ups**:**Re: [eigen] In-place decompositions; was: UmfPackSupport vs SuperLUSupport: input matrix***From:*Christoph Hertzberg

**Re: [eigen] In-place decompositions; was: UmfPackSupport vs SuperLUSupport: input matrix***From:*Gael Guennebaud

**References**:**[eigen] UmfPackSupport vs SuperLUSupport: input matrix***From:*Philippe Marti

**Re: [eigen] UmfPackSupport vs SuperLUSupport: input matrix***From:*Gael Guennebaud

**Re: [eigen] UmfPackSupport vs SuperLUSupport: input matrix***From:*Christoph Hertzberg

**Re: [eigen] UmfPackSupport vs SuperLUSupport: input matrix***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] UmfPackSupport vs SuperLUSupport: input matrix** - Next by Date:
**Re: [eigen] In-place decompositions; was: UmfPackSupport vs SuperLUSupport: input matrix** - Previous by thread:
**Re: [eigen] UmfPackSupport vs SuperLUSupport: input matrix** - Next by thread:
**Re: [eigen] In-place decompositions; was: UmfPackSupport vs SuperLUSupport: input matrix**

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