[SciPy-dev] ARPACK Wrapper update

Neilen Marais nmarais at sun.ac.za
Mon Nov 20 14:17:37 CST 2006


Hi.

I spent some time looking at Nils's problem (I'll follow up on his post), and
also refactoring the wrappers a bit. First off, I'd like to get some opinions.

I think we should structure the modules such that a user doesn't know they are
dealing with ARPACK, but merely a sparse eigensolver unless they want to do
advanced things.  This should be in a module called speigs. It should present
an interface such as Aric's code in arpack.py.

Then there should be a medium-level interface that takes care of ARPACK's Fortran
nastiness for you but let's you use more advanced features. This is what is
currently in the file called speigs.py. The user-level code should call the
medium-level ARPACK interface to get the work done. And of course the raw
Fortran wrappers should be available to control freaks.

The way stuff is now (which is purely a coincidence and not really by design)
is backwards. My code that is now in speigs.py should be in arpack.py, and
vice-versa.

I refactored the code in speigs.py so that the generalised and ordinary solvers
don't duplicade code. I also renamed the function calls to start with ARPACK to
make it clear that they are tied to ARPACK and aren't general user routines. 

So, I propose to:

1) rename speigs.py to arpack.py, and vice-versa
2) Make speigs and arpack separate modules
3) Modify the code in the proposed speigs.py to call the code in the proposed
arpack.py to do the actual ARPACK work

Does this sound good?

At the moment the ARPACK_ functions can handle real, general, double-precision
matrices, and use the following ARPACK modes:

a) Generalised eigen-problems with spectrum shift
b) Standard eigen-problems with no spectrum shift

It should also support:

c) Generalised eigen-problems with no spectrum shift
d) Standard with spectrum shift

Adding c) and d) should not be too much work. Once that is done we should look
for a reasonable way to support complex matrices and other numerical types. I
think Aric's wrappers already address that to some extent, so I'll take a look
there.

Thoughts?

Regards
Neilen




-- 
you know its kind of tragic 
we live in the new world
but we've lost the magic
-- Battery 9 (www.battery9.co.za)



More information about the Scipy-dev mailing list