[SciPy-dev] ARPACK Wrapper update
by Neilen Marais other posts by this author
Nov 20 2006 12:18PM messages near this date
[SciPy-dev] ARPACK_gen_eigs
|
[SciPy-dev] Current status of arpack.speigs.eigvals
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)
_______________________________________________
Scipy-dev mailing list
Scipy-dev@[...].org
http://projects.scipy.org/mailman/listinfo/scipy-dev
|