[SciPy-dev] lapack and blas

eric eric at scipy.org
Fri Jan 18 11:23:37 CST 2002

Hey Pearu,

> Now I would like to re-work with lapack and blas modules in
> scipy. Currently they are included in linalg package but I am thinking of
> separating lapack and blas from there to stand-alone packages into scipy/
> tree. Here are my reasons:
> 1) I don't want to break linalg package.
> 2) lapack and blas packages are valuable also outside scipy environment.

I think some reworking would be beneficial.  Can you give a brief outline of
your plans?  There is hope that the current wrapper generator will also be
able to generate Scalapack wrappers from the same set of generic_lapack.pyf
definitions.  I want to keep this possibility open.  We also need to keep
both c and fortran interfaces so that people using the respective languages
will have a "native" ordering package to use for the fastest possible

Also, I have a small set of routines that overlap with some in linalg that
we use on some high performance (but serial) applications.  They're
interface is necessarily differnt from the current linalg stuff so that
uncessary copying, etc. can be avoided (they have and overwrite=1 flag and
things like that).  I'd like us to revisit the linalg interfaces in the
hopes that we can come up with a design that provides convenience and still
allows for high performance computations.

> Later, linalg would start to use these new lapack and blas packages as
> they should become easier to maintain and more efficient when using the
> latest features in f2py.

Is it possible to just branch the current package in the CVS? I've never
done this (the one time I tried, I screwed everything up).  We can add an
alias in the modules file so that cvs co linalg just grabs the linear
algebra package.  Also, the current build infrastructure makes it possible
build sub-packages in scipy either within SciPy or standalone.  So, if there
are no scipy dependencies in the linalg module, then it should work fine

If we can find a way to do it, I'd like to do it within the current package.
That keeps from having two of them floating around.  Also, it will keep
everybod interested in the re-write involved in it.

I'm all for the re-write though, and am currently interested in the same
topic.  Lets get to it.


More information about the Scipy-dev mailing list