LAPACK and ScaLAPACK Survey Results - ordered by question
LAPACK Usage
Question #13. How could the LAPACK interface be improved to feel more natural to your application and implementation language? | Responses |
|---|
| There could be a facility to interrupt a Lapack call. This can be very useful in a multithreaded application, or one that makes use of asynchronous communication. I hacked this feature into Lapack3 in a fairly inelegant way. I identified several points in the Lapack code to call an external function, which was part of my application that handled communication events. These points were chosen so they were called fairly often during the course of solving my symmetric eigenvalue problem, but not in inner loops to avoid a performance hit. Because the Lapack functions have no parameters for such a purpose, I used "LDA" as a flag to indicate a situation where I need Lapack to abort the current operation, as opposed to just continuing on where it left off. In my application, this depended on the nature of the communication event. | | Object orientation | | see the draft LAPACK bindings of the C++ boost project | |
Fortran 90/95 interfaces would be more natural
Overload so that have one routine name for all data types | | Better integration with Python | | Short of doing a full thing with a generic linear algebra library (modeled after blitz++ or MTL), I favor the pragmatic and simple approach I described in item 12. | | I actually find the procedural interface as it stands quite natural, but then I'm one of the f77 dinosaurs. | | Automatic memory allocation for temporary/work arrays would be a nice option. I understand why LAPACK does the whole bit about 'leading dimension of array...' but it's awkward and clumsy. Would be nicer to use f90 interfaces that know what shape the array is, or a simple C++ array type that does as well. (But *not* a complicated C++ array type like Blitz supplies; don't make LAPACK itself dependent on anything!) | | I don't see any obvious/major weakness to the current
LAPACK (used under F90). | | - removing the work spaces
- call-by-value interfaces for C | | Make a C++ framework for it so I don't have to write my own. | | Some examples that call LAPACK from C would be helpful. | | I hate to call the routine sometimes with underscore on some systems like linux. | | Should have automatic workspace allocation, and would be very useful to have a "higher level" interface that, given the sort of problem to solve (e. g. symmetric eigenvalue problem) detects the type of data and the structure of the matrix, so that the user does not have to rewrite large portions of code while trying different algorithms and modifiying existing code (e.g. when the underlying data changes from real to complex). | | automatic interface. | | It would be nice to have multiple c wrappers for LAPACK that can customize calls to many-option functions. | | Definitely oppose to any f90 interface.
f77/C as is makes it very easy to use with any applications. | | Simple consistent interface such as outputs first, followed by inputs. | | give full C or C++ version of lapack | | generic programming would make lapack more accessible from C++ | | More comprehensive wrapper interface for C++ that does not sacrifice performance (e.g. user keeps control over memory allocation) | | Fortran 90/95/2003 interfaces should become standard. | | Provision of standard C/C++ wrappers | | The symmetric packed routines should be improved. | | Provide interface for row-major storage. | | remove user supplied workspace; do it automatically. More obvious (longer) routine names, although this might break f77 applications. | | Make it more like FLAME | | Hide work arrays, leading dimensions, matrix dimensions, and possibly other matrix information (symmetric, triangular) beneath an abstraction layer (a la FLAME objects). Do not require user to provide workspace. | | provide C headers + assistance tool for linking
(linking of Fortran and C can be a bit of a pain in the backside, finding all libraries that have to be linked in) | | More optional arguments and thus shorter method signatures. | | Getting rid of some of the explicit indexing would be nice. Being able to shift the borders of the "matrix of interest" inside the larger array on the machine would be nice. ScaLAPACK makes this situation worse, which is unavoidable I suppose. A very simple change would be slightly less cryptic identifier names (indirect feedback from anyone I help use LAPACK for the first, and often last, time).
| | Object oriented framework for C++. | | Heavy use of C++ | | simplifying the indexing | | We have C++ application codes. We would like to have matrix 'objects' which would bundle size information, and possibly have various format/layout options (e.g. packed symmetric, etc.).
| | Automated memory allocation. | | with a matlab wraper | | It's a pretty good interface as is. | | It would be slightly nicer to have actual routines to query accuracy of eigenproblem results as error bounds from the routines such as zgeevx (that calculate eigen-condition numbers). Right now, the LUG shows (eg. lug/node100.html) code fragments to obtain such accuracy results based on working precision details and the computed condition numbers. It'd be slightly nicer to have these code fragments be actually implemented in some routine -- the driver, say, or other.
| | Using lapack in C++ makes more sense if the library is templated. Allowing to use your own datatypes in the algorithms and hence ennabeling multi-precision.
| | Consistent and intuitive ordering of function parameters/argument | | possibility to have more info about lower level steps in higher
level routines | | provide standartized c++ templated lapack wrappers | | Since we predominantly use OCaml as implementation language, we are not particulary dependent on the LAPACK-interface itself, because the intermediate LACAML-interface makes calling LAPACK very easy without losing functionality or efficiency. I assume that this is also mostly true for other people using different implementation languages. Therefore, I'd propose to keep LAPACK as efficient as possible, i.e. there is no need to waste implementation effort on making it more convenient. Higher-level interfaces and implementation languages are more suitable for this purpose. | | With fortran 95 and even more with Fortran 2003 many things could be improved using the new functionnalities as MODULE, genericity, optional arguments, dynamic allocation of Fortran 2003 and its object oriented programming and C-Fortran compatibility. | | C++ wrapper | | A C interface would make LAPACK feel more natural in C. It might also be nice to have set of functions which have a restricted set of arguments that work for most "simple" problem. FFTW supplies such function and I find them quite handy. | | A simplified interface for Fortran90 etc. that allows for simple quick use of the routines. | | I think it is not necessary to make such improvements. | | I think it is not necessary to make such improvements. |
|