[SciPy-dev] new sparsetools + umfpack
Nathan Bell
wnbell at gmail.com
Wed Jan 10 08:31:52 CST 2007
On 1/10/07, Robert Cimrman <cimrman3 at ntc.zcu.cz> wrote:
> ->>>>>>>>>> 0.249101161957
> rezidual: 0.08 [s]
> solve: 3.27 [s]
> matrix: 0.76 [s]
> nls: iter: 1, out-of-balance: 4.214136e-07 (rel: 2.317289e-03)
> ->>>>>>>>>> 0.244355916977
> rezidual: 0.10 [s]
> solve: 3.29 [s]
> matrix: 0.78 [s]
> nls: iter: 2, out-of-balance: 2.091538e-09 (rel: 1.150105e-05)
>
> ensure_sorted_indices() call is denoted by '->>>>>>>>>>' so it is
> definitely more than 10%. Note that I have a modified version of
> umfpack.py, which calls ensure_sorted_indices() in symbolic() only (call
> in numeric() is not needed).
>
I may be misreading this, but isn't it 0.25/3.27 ~= 7.6%?
> I agree generally, but on the other hand installing umfpack itself is
> not trivial either - such people usually know what they are doing.
> The default solver code path would not be touched, of course...
That's a fair argument. I have one more suggestion though. Suppose
we implemented a function check_sorted_indices() in sparsetools. This
(trivial) function should be a few times faster than
ensure_sorted_indices(), and perhaps it would reduce the overhead to
something on the order of 1-3%. This test could even be used within
ensure_sorted_indices() to possibly avoid the first sort.
e.g.
void ensure_sorted_indices(){
if(check_sorted_indices())
return;
else
//do normal sort
}
Re: Matthew Brett
> Maybe different interfaces for sorted and (possibly) unsorted? Or is
> this not practical?
That would be a reasonable place - anyone who called it with
non-standard arguments would take on the responsibility of sorting
themselves. Anyone who just wanted to solve a few systems could
safely ignore sorting issues.
--
Nathan Bell wnbell at gmail.com
More information about the Scipy-dev
mailing list