ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> scipy-dev
scipy-dev
[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

Privacy Policy | Email Opt-out | Feedback | Syndication
© 2004 ActiveState, a division of Sophos All rights reserved