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
