[SciPy-dev] new sparsetools + umfpack

[Nathan Bell]

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