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