Hi Patrick, My TODOs for 2.0 include... -- Merging some code for Konrad (the same Hermite stuff you mentioned) -- Merging the two B-spline workspaces into one
On the libflame/LAPACK question you raise, and out-of-order response to 5 before 1 though 4.... > 5. Is there a strong preference for doing wrappers for both lapack and > flame? Should we only interface to lapack, due to the difficulties with > flame (global state, abort() error handling)? Should we only interface to > flame due to its more modern design? Maintaining two sets of linear algebra backends is error prone and will stretch our already thin time to hack on GSL. We might take an intermediate approach and target http://www.netlib.org/lapack/lapacke.html. That'll solve C-to-Fortran linkage hell for legacy LAPACK (assuming vendors support it) and aiming for the standard-ish API follows the GSL precedent of writing to the CBLAS API. As libflame has a LAPACK-compatibility layer ("lapack2flame"), any LAPACKE "shim" permitting talking to a legacy LAPACK would also permit talking to a fairly large subset of libflame. Assuming success with that LAPACKE idea and a good driving use case, we could marry GSL more closely with libflame down the road. > 1. Should we try to add lapack/flame interfaces for the 2.0 release or wait > until 3.0? I personally probably won't have a lot of time to work on this > for several months. Ditto here on the time crunch for a few months (stupid overdue thesis). I'd aim for LAPACKE in 2.0 and, if needed, tighter libflame in 3.0. > 2. Is it better to select gsllinalg/lapack/flame at compile time or link > time? Link time, and presumably an invisible thing for us with LAPACKE provided that the Autoconf infrastructure can find something sensible for 'make check' > 3. Whats the best way to handle the memory workspace requirements (add > _alloc functions to all gsl_linalg routines or dynamic allocation)? Use of high-level LAPACKE claims to handle workspace allocation. If it becomes performance critical somewhere, we could manage it internally and use the medium-level API along with explicit management. > 4. What should we do about error handling in libflame? Just accept the > abort() behavior? If libflame's LAPACK-compatibility does not include proper error handling and just calls abort(), well, that would be their problem to fix if they claim compatibility. Once upon a time I got Brian's permission to yank the gsl_error infrastructure for libflame and submitted a patch. That can be dug up if they want/need it. - Rhys
