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