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

[Liam Healy]

On Wed, Apr 9, 2008 at 10:13 PM, Zach <elzacho at gmail.com> wrote:
>
>
>
> > To tell you the truth, I never looked closely enough at views to
> > figure what it would take to make them work.  It may be trivial, or it
> > may be impossible.
> >
>
> Yeah, I now believe my suspicions to be correct, at least as of a year and
> half ago.  Maybe there have been some advances as CLISP seems to support the
> needed feature and I'd bet the C friendly ECL and GCL both do as well, still
> no idea on SBCL.
>
>
> > One thing to keep in mind is that I am rewriting what
> > I call "data" (matrix, vectors, etc.) to use Tamas Papp's
> > foreign-friendly arrays.  On SBCL, this will mean that the CL array
> > and the C array will be one and the same (no copying).
>
> Hmmm... that sounds good, still not sure how Tamas' FFAs would work.  I was
> preparing to suggest the *other* route that Tamas mentions on his page,
> basically using the GSL data structures thinly wrapped in a Lisp object (to
> tie it into the GC).  I guess both have their pros and cons.

I'm not sure what that is, I guess I'll have to re-read his page.  I
do remember him mentioning another approach used  by rif for blapack,
and that is don't-copy-unless-necessary.  I think my design will be
the best of both worlds:  on SBCL it will use the native array, but
the usage is such that on non-SBCL platforms, there won't be any
copying unless necessary.  So chained foreign calculations will stay
on the foreign side.  This will be much like it is now with the
#'cl-invalidate function that merely marks the CL copy to be bad but
doesn't copy it back until #'data requests the data on the CL side.

>
> BTW, I have one question, purely out of curiosity.  Even if you use an FFA,
> GSL is going to expect data in the format the GSL developers designed, e.g.:
>  00 01 02 03 XX XX XX XX
>  10 11 12 13 XX XX XX XX
>  20 21 22 23 XX XX XX XX
>  Which means that either the Lisp array will have extra junk to carry
> around, and hence new matrix operations will need to be defined, or some C
> side trickery must be performed to translate it, which is what we are trying
> to avoid, right?  How do you deal with this (or plan to)?
>
I use the necessary GSL structures currently (see e.g. gsl-vector-c).
These have a
data pointer.  Currently, that points to space allocated by GSL
through the generic function #'alloc (which ultimately calls something
like gsl_vector_alloc).  The use of the GSL structure will continue,
but FFA will assign the pointer to the C array.  If using SBCL, that
pointer will actually be to the Lisp data but it will work as the C
array due to the foresight of the SBCL designers.

(I'm assuming by "extra junk" here you mean the parts of the GSL
structs that aren't the array itself.)

Liam