[SciPy-dev] symeig integration ready

Tiziano Zito opossumnano@gmail....
Tue Nov 18 12:05:44 CST 2008

Dear devs, 

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 mailing list