[SciPy-dev] blas/lapack interfaces

[Pearu Peterson]

On Tue, 28 May 2002, eric wrote:

> > Pearu wrote:

> > I agree. Having the C interfaces around is useful only if there is a
> > memory issue.
> 
> Lets keep them.  Your packaging in linalg makes the fail over to
> flapack completely transparent, so the only cost is maintaining the
> code.  That may not be a small cost though -- these wrappers
> definitions are pretty dang complex now.  I saw that you split the
> Fortran and C wrappers files at some point.  I had really wanted to
> avoid this to help with maintainability but assume it was done to
> handle the callstatement() stuff.  I do wish they were still unified.
> Do you think it might be possible to introduce a <c_section> and
> <f_section> tag to our interface_gen generic scripts to include
> specific sections in the generated interface files depending on the
> target language?

I did that split in order to avoid complexity when it was not really clear
how these signatures will look like (in this process new features to f2py 
were added). However, the signatures to Fortran and C routines were
created in parallel to ensure the compability. Also, you'll see that
signatures to the same Fortran or C routine are in some cases quite
different (because C and Fortran routines require a bit different
strategies for wrapping and managing memory of temporaries, also
BLAS?LAPACK interfaces of the same routine but for complex or real
input data may differ etc.) but their apparence in Python is
(almost) identical (some wrappers to C routines have extra optional
arguments to handle data ordering issues with additional flexibility).

But now, when the most important BLAS/LAPACK routines are exposed and we
have basic unittests (and need more), I agree, that the next step would be
to merge the signatures of Fortran and C routines to ease the
maintainability. And yes, introducing <c|f_section> tags are possible when
doing that.

In addition, I would like to suggest splitting the current generic
signature files into smaller files, each containing signatures to one
particular routine. Having different routine signatures in separate files
(collected in some subdirectory of scipy/linalg), IMHO, they will be 
easier to maintain and discuss compared to its current form where the
generic files, containing a large number of different signatures, are
quite longish and difficult to handle.

And we need to document the blas and lapack functions. I hope we can do
that while reviewing-testing-freezing the signatures.

Pearu