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

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

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

I guess, you mean ApplyTransposeOnTheRight -- actually a powerful argument for having a more readable, less error-prone syntax.

So this just gave me the idea that we could imagine doing:


If A is compatible enough with dec, we could simply exchange pointers.

An alternative would be to add a "grab" function:


dec would "grab" the memory available in A, make A an empty object,
and then perform the factorization.

These solutions would be limited to dynamic matrices, I guess? I admit however that I don't have any better API-ideas at the moment. Maybe sth like dec.share(A), which changes A but leaves it a valid matrix (basically what FullPivLU::matrixLU() et al. return). However dec would become invalid as soon as A is changed again which would be very hard to detect automatically (and also hard to prevent).

A fixed-size use case I would have is to have a lot of rather small fixed size matrices which are accumulated simultaneously and shall all be decomposed, once the accumulation is done.

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).


Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252

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