Re: GSL v2.0 discussion

[Rhys Ulerich <rhys.ulerich@gmail.com>]

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