Re: [eigen] Re: Map and pointer freeing in unsupported/Eigen/src/SparseExtra/CholmodSupport.h

[ Thread Index | Date Index | More Archives ]

On 31.07.2011 00:58, Douglas Bates wrote:
On Sat, Jul 30, 2011 at 5:06 PM, Douglas Bates<bates@xxxxxxxxxxxxx>  wrote:
        /** \internal */
        template<typename Rhs,typename Dest>
        void _solve(const MatrixBase<Rhs>  &b, MatrixBase<Dest>  &dest) const
            eigen_assert(m_factorizationIsOk&&  "The decomposition is not in
a valid state for solving, you must first call either compute() or
            const Index size = m_cholmodFactor->n;

            // note: cd stands for Cholmod Dense
            cholmod_dense b_cd = viewAsCholmod(b.const_cast_derived());
            cholmod_dense* x_cd = cholmod_solve(m_solveType, m_cholmodFactor,
                this->m_info = NumericalIssue;
            // TODO optimize this copy by swapping when possible (be carreful
with alignment, etc.)
            dest = Matrix<Scalar,Dest::RowsAtCompileTime,Dest::ColsAtCompileTime>::Map(reinterpret_cast<Scalar*>(x_cd->x),b.rows(),b.cols());

It appears to me that the last two lines change the dest argument to
map the storage from the (x_cd->x) pointer then free that storage
(cholmod_free_dense frees all the storage pointed to by the members of
the cholmod_dense struct).

The same seems to be true in the _solve method for a SparseMatrix,
which ends with

	    // TODO optimize this copy by swapping when possible (be carreful
with alignment, etc.)
	    dest = viewAsEigen<DestScalar,DestOptions,DestIndex>(*x_cs);

I would say there won't be an easy and save fix, because one can't be sure what kind of allocator CholMod uses on different platforms or in future versions. A save way would be to do the triangular solve operations with own code (or is there a CholMod function which works on views instead of allocating own memory?).

viewAsEigen will return a MappedSparseMatrix with pointers to contents
that will be freed in the subsequent line, unless I am missing
something subtle.

The comments about swapping lead me to believe that the dest argument
has storage allocated on entry to the function, in which case the
values could be copied from the structs&x_cd or&x_cs.  I must admit
I get a little lost in the details of the sparse_solve_retval struct
so if anyone could tell me the status of the Dest argument when the
_solve method is called, I would appreciate it.  In particular, for a
dense return value, has the storage for the data already been

cholmod_solve allocates its own result vector (stored in x_cs). dest is a parameter of _solve(). Currently the values _are_ copied (which technically is not necessary). If one assigns a solve_retval object to a vector x, then solve_retval's evalTo function is called with parameter x.


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

Tel: (+49) 421-218-64252

Mail converted by MHonArc 2.6.19+