Re: [eigen] UmfPackSupport vs SuperLUSupport: input matrix

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

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.


gael



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