Re: [eigen] Allocation policy of eigen decompositions

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


Dear Adolfo,

and while you're at it - it would be also useful to have the
decompositions (or, at least in my case, HouseholderQR) work
optionally in-place. Internally, HouseholderQR copies its argument
into its member m_qr of the same type and performs the decomposition
on that, so it would be easy to expose this behaviour as an option, at
least for decompositions without pivoting. Benoit, you being the
master of the decompositions API, what do you think?

Marton

2010/3/5 Adolfo Rodríguez Tsouroukdissian <dofo79@xxxxxxxxx>:
> Hello,
>
> I have a question on what the allocation policy of the eigen 3.x matrix
> decompositions will be, for this will strongly bias how I use eigen on
> different parts of my code.
>
> On the one hand, I know that the template parameters of the matrix to be
> decomposed (size, options, max size, ...) will be propagated to all the
> decomposition's members and temporaries [1], so if the input matrix is
> stack-allocated, so will be the internals of a decomposition. So far so
> good.
>
> On the other hand, I had the expectation that if heap-allocated matrices are
> used, all heap allocations of the decomposition algorithm would take place
> during the initialization phase, and none would be done in the computation
> phase (provided that the initialization and computation matrices have the
> same size in memory). This currently does not seem to be the case. For
> example,
>
> MatrixXd I(MatrixXd::Identity(16, 16));
> MatrixXd A(MatrixXd::Random(16, 16));   // Same size as I
>
> Eigen::FullPivLU<MatrixXd> lu(I);       // Allocates 5 temps
> lu.compute(A);                          // Allocates 2 extra temps
>
> Eigen::JacobiSVD<MatrixXd> svd(I);      // Allocates 4 temps
> svd.compute(A);                         // Allocates 1 extra temp
>
> I haven't checked where the extra allocations in compute() come from, but my
> question is, can and will they be prevented for 3.x? or is this an
> intentional design decision? (and if so, for what reasons).
>
> TIA,
>
> Adolfo
>
> [1]
> http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2010/03/msg00095.html
>
>
> --
> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
> AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden
> contener información privilegiada y/o confidencial que está dirigida
> exclusivamente a su destinatario. Si usted recibe este mensaje y no es el
> destinatario indicado, o el empleado encargado de su entrega a dicha
> persona, por favor, notifíquelo inmediatamente y remita el mensaje original
> a la dirección de correo electrónico indicada. Cualquier copia, uso o
> distribución no autorizados de esta comunicación queda estrictamente
> prohibida.
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only for
> the individual or entity to whom they are addressed.  If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution or use of this e-mail and/or accompanying document(s) is
> strictly prohibited.  If you have received this e-mail in error, please
> immediately notify the sender at the above e-mail address.
>



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