[Gsll-devel] What is needed to fix matrix views?

[Liam Healy]

On Thu, Apr 10, 2008 at 12:31 PM, Zach <elzacho at gmail.com> wrote:
>
> So, here is what I don't get:  How can (aref mat i j) equal
> gsl_matrix_get(mat, i, j) even if mat is somehow the same object?  The
> functions gsl_matrix_get and aref possibly do two very different things.
> Perhaps they do the same thing in SBCL, in which case everything about FFAs
> would make sense until someone writes another format for
> matrices/vectors/etc.

In SBCL (and CMUCL too), there is a function vector-sap which gives
the C pointer
of a simple array with a declared type.  This can be passed to a C
program when in a with-pinned-objects macro (to prevent garbage collection while
C is working on it).  Tamas has some definitions to allow
multidimensional arrays,
copying etc.  I'm pretty sure they won't rewrite the format for arrays to break
compatibility with C access, but if they do the fallback is what is done for all
non-SBCL implementations now: copying.

>
>
> If we forget about all of the structure slots and go down to the underlying
> 1D array that represents matrices we have this.
>
> gsl_matrix_get(mat, i, j) = mat->data[i * mat->tda + j]
>
> tda here does not, in general, equal the width of the actual data.

I'm not sure what you mean here, but if GSL is happy with the data stored
as a standard C array at the heart of it all, then the SBCL vector-sap should
do just fine.  The trick is to not have GSL do the allocation of that array.
It must be allocated by SBCL and in the SBCL address area, and then passed
on to GSL.  So routines like gsl_vector_alloc are not used anymore.
I am manually creating a GSL block (using CFFI) and putting this
pointer in it, then
using GSL's gsl_vector_alloc_from_block.

Liam