| Re: [eigen] new API for Cholmod |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
Hi,
i,
I've started to rework our sparse solvers/backends with Cholmod. The
old API is still available.
The first difference is that there is no SparssLLT or SparseLDLT or so
base classes which was really confusing to use.
Instead, you directly use the relevant wrapper class,
CholmodDecomposition<MatrixType,UpLo>:
[snip]
You can also configure the underlying decomposition with:
chol.setMode(mode);
[snip]
It is not that much changes but I think this approach is much cleaner
and easier to use.
I plane to write all solvers/wrappers using the same model, so it is
perfect time to give your opinion on what would be the best API for
them. The constraint is that we must be as close as possible to the
dense API, but it is perfectly reasonable to add convenient methods
with more runtime facilities....
Cool, this is great news to me !
As previously discussed, I believe that the runtime of most (all ?)
member function calls on sparse matrices and the lack of compile-time
unrolling through fixed size makes static polymorphism pointless for
such use cases, so I'll be glad to get the ease of use of runtime
polymorphism instead.
Wrt API, I think it should be possible to closely follow the dense API
with the only addition of your setMode(XXX) with XXX being the run-time
equivalent of the compile-time template parameters.
Then we could imagine to have a meta solver built on top of them with
runtime registration of backends, priority rules, etc. but that's
another story.
The main difference is that the availability of backends could be
checked
at runtime instead of compile-time. That would be an asset when
shipping binaries using system libraries (e.g. libsparsesuite,
libumfpack on Debian). Do you have plans/ideas to support this ?
Speaking about backends, I am wondering how hard is it to write a new
wrapper.
I'd be interested in CSparse for instance :
The good news is that it is CCS, but the Eigen doc[0] warns about a
difference:
"unlike several other sparse libraries (e.g., CSparse), the
coefficients of our CCS matrices are always sorted. " Am I right to
believe that this won't be a stumbling block ?
One of my reasons to be interested by CSparse is that the LU
decomposition is rank revealing : is there another way to compute the
rank with currently supported Eigen backends ?
(I would also be insterested in SPRSBLKLLT)
On the subject of backend choice, maybe it would be useful to add a few
references (I not qualified to evaluated the, but I found [1] anf [2] to
be interesting.), in the doc (maybe @[3]).
Kind regards,
Bernard
[0]
http://eigen.tuxfamily.org/index.php?title=SparseMatrix#Current_state
[1] http://www.cise.ufl.edu/research/sparse/codes/codes.pdf
[2] ftp://ftp.numerical.rl.ac.uk/pub/reports/ghsRAL200505.pdf
[3]
http://eigen.tuxfamily.org/dox-devel/TutorialSparse.html#TutorialSparseDirectSolvers