Re: libflame version 4.0 announced

[Brian Gough <bjg at gnu dot org>]

At Wed, 17 Feb 2010 15:47:49 -0700,
Gerard Jungman wrote:
> I just want to link against it, presumably through
> some GSL-owned insulation layer, which can be
> configured to point to any conforming implementation.
> Similar to the BLAS wrapper layer.
> 
> But this requires some kind of interface design. With
> BLAS we were lucky that a standard C interface existed
> already. But it's not so clear what a "standard" LAPACK
> interface would look like. It's very nice that they have
> gifted us with their implementation and their interfaces
> for a model. But it doesn't leave us entirely off the hook.
> 
> The other big problem is what to do with their data
> structures. Obviously we need an insulation layer to
> protect clients from changes in FLA_Obj and friends.

I envisioned two simple things to add FLAME support in GSL:

- a set of wrapper functions to call the high-level flame routines
  (Cholesky, LU, QR etc) with gsl_vector/matrix arguments (via the
  simple create+attach_buffer method, as in the FLAME/C examples in
  the manual).

  This would be a direct alternative to the gsl_linalg routines.

  e.g. gsl_linalg_LU_decomp (gsl_matrix * A, gsl_permutation * p, int *signum)
  => gsl_flame_LU_decomp (gsl_matrix * A, gsl_permutation * p)

- a few (trivial) utility functions to convert from gsl_vector/matrix
  to FLA_Obj.

-- 
Brian Gough