On Thu, Apr 10, 2008 at 12:31 PM, Zach elzacho@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