|Re: [eigen] SparseLU generates dense representation somewere|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
Thank you, that fixed the crash. But this way it's certainly too slow to be
usable, since the dense matrix is still generated slice by slice :)
(5 minutes, still running).
Do you think that it would bepossible to hack the defaultEvalTo() function
to use a SparseVector with NbColsAtOnce==1, or is it more involved than
that? At least in principle I think it would be useful if a fully sparse
solve() function is provided as an alternative option.
On 1/19/14, 3:15 AM, Christoph Hertzberg wrote:
> On 18.01.2014 22:19, Wenzel Jakob wrote:
>> So it seems like for some reason it is allocating a dense
>> representation. What am I doing wrong?
> It appears that the sparse solver currently takes the rhs 4 columns at a
> time, converts it to a dense matrix, solves the dense system and copies a
> sparse version of the result to the result matrix.
> The temporary matrix had as many columns as the result matrix, which I
> fixed here: https://bitbucket.org/eigen/eigen/commits/b75890d
> That resolves the issue of bad::alloc, but still is extremely slow for your
> simple example.
> I assume, if all the systems are very sparse, an optimized version which
> only uses sparse matrices/vectors could be implemented. However, that will
> likely turn out slower for matrices with higher fill grades.