Liam, Tamas,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">IMO this idea is easy to implement (and optimize to death, with<br>

compiler macros) in Lisp.  I see no need for special glue to GSL's<br>
views, which are less general (matrices only, specialized view types<br>
etc) and reflect the limitations of C.  GSL is a great library, but I<br>
don't think we should take pains to implement glue to stuff that is<br>
much easier and faster to write in Lisp.<br>
</blockquote><div><br>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.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

What do you gain?  A general affine map for indexing you can use for<br>
multidimensional arrays and any kind of view you can imagine.</blockquote><div><br>This would be very handy.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What do you lose?  You can no longer use aref and array functions.<br>
That is actually a big loss, that's why I didn't do it, </blockquote><div><br>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?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">also, I found<br>
displaced arrays general enough.</blockquote><div><br>You mean in conjunction with the affine parameters?  You cannot encode the affine map in terms of :displaced-to and :displaced-index-offset, right?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But the above is easy to do, I have<br>
some code lying around if you are interested.</blockquote><div><br>I am interested, could you post it?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

When I wrote FFA, I did it because I decided that for my applications,<br>
putting the data in foreign memory is not worth it.  The idea behind<br>
FFA is that we want to interoperate with foreign libraries, but still<br>
want to do most of our calculations in Lisp, so setting up a data type<br>
that resides in foreign memory is unwarranted (you lose a lot of nice<br>
stuff that way, incl painless memory management).<br></blockquote><div><br>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.<br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also understand that copying is very cheap, cheaper than most people<br>
realize.  So if you just want a submatrix from a matrix, it is not<br>
that expensive to simply copy it into another matrix.  Do you have<br>
some application where you think views would be of huge importance?</blockquote><div><br>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.<br>
<br>Thanks,<br>Zach<br><br></div></div>