[SciPy-Dev] ARPACK fixes before 0.9

Pauli Virtanen pav@iki...
Mon Nov 29 05:38:44 CST 2010

Sun, 28 Nov 2010 20:45:25 -0700, Aric Hagberg wrote:
> I am actually to blame for the original interface.  David made my hack
> work correctly and deserves credit for the good parts.

Ah sorry, I only looked at the committer in "git blame" :)

> I took a look at your branch and it seems fine to me.
> The name changes makes sense though maybe svd should be svds to match
> the eig->eigs pattern between the numpy and sparse implementations?

Yes, that seems reasonable.

> (Similarly should eigs_symmetric be eigsh  to match numpy.linalg.eigh?.
> It would need to be extended to handle the complex case).

There doesn't seem to be any special support for Hermitian matrices in 
Arpack, so I'm not sure which is better, (i) to raise an error on complex-
valued input, or (ii) to fall back to eigs().

> I made some suggestions for documentation improvements at
> https://github.com/hagberg/scipy-work/tree/bug/1313-arpack

Ok, thanks!

Mon, 29 Nov 2010 14:12:53 +0900, David Cournapeau wrote:
> The PROPACK method has been fairly well documented, though, with both
> fortran and (early) matlab implementation, so it is doable. The
> original code cannot be used as is anyway because of some hardcoded
> limitations.
> Besides speed, the main issue with solving A^h A is precision, I was
> thinking about adding support for solving [A 0; 0 A^H] which is more
> precise (but much slower), but never got around it. Should be fairly
> easy to add.

Sparse SVDs probably need more work later on. From what you say, the 
easiest approach seems to write the code for them from scratch, based on 
some papers. I don't have a need for SVDs myself at the moment, so it's 
for later.

> For the parts I am familiar with, the changes made sense - but as Aric
> mentioned, I have only contributed the svd part. 
> There are still some
> hard (causing crash) bugs in the arpack submodule, but I suspect it is a
> bug in arpack itself: when I tried to debug it, it was out of bound
> array indexing in some cases, which did not seem to be caused by invalid
> input. I think I would rather spend time implementing better algorithms
> than debugging unstrucuted, goto-ridden fortran code :)

At least one crash due to out-of-bounds access was fixed by applying 
a patch from Debian. Let's hope there are not more of them...


More information about the SciPy-Dev mailing list