[SciPy-dev] new sparsetools + umfpack
wnbell at gmail.com
Wed Jan 10 07:35:13 CST 2007
On 1/10/07, Robert Cimrman <cimrman3 at ntc.zcu.cz> wrote:
> New sparsetools implementation does not require CSR/CSC column/row
> indices to be sorted in ascending order, while UMFPACK does. Currently,
> every call to umfpack module (e.g. via linsolve.solve) implicitly calls
> ensure_sorted_indices(inplace=True) method of CSR/CSC matrix, which is
> rather fast, but in many cases is not necessary and the overhead can
> become significant when solving lots of linear systems (e.g.
> FE-discretized evolutionary nonlinear PDEs) - in this case, only one
> call to ensure_sorted_indices() is necessary, then only values change,
> not the structure.
I remain unconvinced that this is a real performance problem. Given
the speed of ensure_sorted_indices(), (it's even faster than copy()) I
can't see how repeated calls would increase the total run time by more
than a few %. Do you have evidence that this is a bottleneck?
> Therefore, if there are no objections, I would like to remove the
> implicit call to ensure_sorted_indices() from umfpack and require user
> to call it explicitly (only if necessary) - an exception will be raised
> by umfpack if the matrix is not in correct form, so it cannot lead to
> hidden bugs. I will document this in linsolve, of course.
Personally, I think it's best to hide these details from the user as
much as possible. If the performance penalty is more than 10%, then
perhaps it should be changed. Otherwise I think simplicity wins.
Keep in mind that many SciPy users have little interest in learning
the underlying implementation of things like sparse matrix formats.
Informing them to use lil_matrix for construction but csr_matrix for
arithmetic is fine (they can just take your word for it), but
requiring that they ensure_sorted_indices() before calling umfpack is
a bit too much IMO.
Nathan Bell wnbell at gmail.com
More information about the Scipy-dev