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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Tue, Apr 16, 2013 at 3:49 PM, Christoph Hertzberg
<chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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.

yes, OnTheRight !

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

damn, I was not expecting use cases for small fixed size matrices, but
yours is perfectly reasonable. Then there are two approaches, either
the factorization uses the memory shared by the matrix A, or we create
a decomposition and then get a writable reference to the storage
matrix.... The second approach is less flexible and uglier but it is
already doable by const-casting the matrix reference returned by
matrixLU().

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