[SciPy-dev] symeig integration ready
Tue Nov 18 12:05:44 CST 2008
I have managed to integrate symeig in scipy, but before
doing a commit I would like to get your feedback:
- scipy.linalg.eigh gets the following signature:
eigh(a, b=None, lower=True, eigvals_only=False, overwrite_a=False,
overwrite_b=False, turbo=True, eigvals=None, type=1):
this is different from the current signature:
eigh(a, lower=True, eigvals_only=False, overwrite_a=False):
Is it OK to break backward-compatibility? Code would only break if
someone was specifing keyword arguments as positional arguments...
Same thing for the eigvalsh routine.
- I added the pyf wrappers for the new lapack routines in
generic_lapack.pyf . They look somewhat different from all other
wrappers (they were written 6 years ago without scipy in mind).
In the long run I think those fortran routines should get the same
kind of wrappers all others have, but I can not do such a
rewriting without the guidance of the guy who wrote the
generic_XXX.pyf in the first place, which I assume is pearu. In
particular the calc_lwork.f module puzzles me.
The new lapack routine get the minimum "lwork" and not the optimal
one, which should be delivered by calc_lwork, if I only knew
- I added 129 tests to test_decomp.py using the marvelous nose
parametric tests feature. They run pretty fast, and they excercise
all relevant lapack routines with most (but not all) combinations
of parameters. Is it OK? Should I flag those tests as "less"
important so that they are not run by default?
If everything is all right with you I would commit the changes
tomorrow. I will also continue to provide symeig as a standalone
module until scipy 0.7 is released and a corresponding debian
package is available. A new release with all changes (and bug-fixes
:-)) I made to incorporate it in scipy will be released soon.
Let me know,
More information about the Scipy-dev