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

[Zach]

Liam, Tamas,

IMO this idea is easy to implement (and optimize to death, with
> compiler macros) in Lisp.  I see no need for special glue to GSL's
> views, which are less general (matrices only, specialized view types
> etc) and reflect the limitations of C.  GSL is a great library, but I
> don't think we should take pains to implement glue to stuff that is
> much easier and faster to write in Lisp.
>

This afternoon I spent a bit writing GSL's matrix data types in terms of
Lisp functions and data.  Agreed, it is much easier/faster/more natural to
do this in Lisp.

What do you gain?  A general affine map for indexing you can use for
> multidimensional arrays and any kind of view you can imagine.


This would be very handy.

What do you lose?  You can no longer use aref and array functions.
> That is actually a big loss, that's why I didn't do it,


One would hope that this isn't too big of a loss.  Different data types have
different interfaces right.  Are you referring to the inability to use other
peoples tools?

also, I found
> displaced arrays general enough.


You mean in conjunction with the affine parameters?  You cannot encode the
affine map in terms of :displaced-to and :displaced-index-offset, right?

But the above is easy to do, I have
> some code lying around if you are interested.


I am interested, could you post it?

When I wrote FFA, I did it because I decided that for my applications,
> putting the data in foreign memory is not worth it.  The idea behind
> FFA is that we want to interoperate with foreign libraries, but still
> want to do most of our calculations in Lisp, so setting up a data type
> that resides in foreign memory is unwarranted (you lose a lot of nice
> stuff that way, incl painless memory management).
>

Okay, so I guess I get it.  Given the data structure the GSL docs describe,
even with FFAs we cannot use AREF to access the data in the array.  This is
because we may be looking at a submatrix.  However, since matrix views are
perhaps the only time that a GSL function returns a submatrix (and we don't
use that), we are always dealing with full matrices (tda = width).  Thus
nothing to worry about and we can use AREF.

Basically we are porting the functions like gsl_matrix_alloc to the Lisp
side.  Of course this means that we are sensitive to changes in the
underlying GSL data type, even when C programs are not.  You are right Liam,
this does seem like a good compromise.

Also understand that copying is very cheap, cheaper than most people
> realize.  So if you just want a submatrix from a matrix, it is not
> that expensive to simply copy it into another matrix.  Do you have
> some application where you think views would be of huge importance?


Of course this all came about from my naive attempt to create a GSL binding
without understanding what is happening underneath.  Hence there is no
application in mind.  However, there is something to be said for elegance
and fluidity in code.  Then again, one must accept that this is out the
window when using C.

Thanks,
Zach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/gsll-devel/attachments/20080410/f688c37a/attachment.html>