On Fri, Apr 11, 2008 at 10:56 AM, Tamas K Papp <tpapp@princeton.edu> wrote:
On Fri, Apr 11, 2008 at 10:26:41AM -0400, Liam Healy wrote:
Tamas,
I like your ideas on general array views, it seems very standard; I think what we're all talking about is array slicing http://en.wikipedia.org/wiki/Array_slicing. I understand and support
Liam,
It seems that my idea is more general. With affine maps, you can do index rearrangements (eg reorder rows/columns in reverse order) and lot of other fancy stuff.
Ah, OK. That seems like it would indeed be easy to implement, and e.g. makes a transpose trivial.
the desire to take advantage of everything Lisp has to offer, however, I would like to maintain compatibility with GSL and other foreign code to the extent possible where there is an analogous concept implemented, so we can take advantage of their functions (that's the idea behind GSLL after all). It seems to me that FFA should work just fine. Perhaps Zach can confirm that GSL's views work the way I expect in matching your general array views description, then your scheme should map into GSL's views. I think your general array views will give CL access to an underlying "full" array, and GSL's view can be made to match, and FFA can provide the option that the underlying full array is one and the same (on SBCL) or properly copied (everywhere else).
Currently, the affine maps are not in FFA, but it appears that views in GSL need them. If you need affine maps, let me know, I can whip up something on top of the current FFA (so even with these very general arrays, one could always access the underlying Lisp array if needed, I consider that an advantage).
For the type of affine map that GSL views support, would it be straightforward to support those views through FFA? If so, go ahead and whip it up.
As far as the aref issue goes, I don't see it as a problem. I currently define #'maref which could be used as is, or #'aref could be shadowed out of the CL package if the user desires. You could even do this in CL code written by someone else by putting the shadow in the package definition.
Indeed you can shadow aref. But code that assumes that some variable is a Lisp array when it is not could get into trouble by other ways, eg using row-major-aref, displacing it, etc. I would prefer if the fancy array type with affine mapping were kept separate.
OK. I would probably not shadow this symbol, but it can be done for code that avoid the troublesome spots you mention.
I understand to desire to provide the whole interface to GSL, but in my opinion, implementing views is not central for Lisp users and leads to more confusion than it is worth. For the moment, I would suggest that we think about views more carefully, write a toy implementation that on top of ffa and try to see what the issues are.
Right, this was my motivation for skipping over them in the first place. As I said before, I didn't even bother to figure out if they would work. They just seemed unimportant. I think native arrays via SBCL are more important, so that's what I've been focusing on (to the extent that I've had time to work on GSLL).
Because Lisp arrays and affine mapping arrays are separate things, what GSLL functions accept and return is also an issue. I could have a matrix that is a Lisp array, or a matrix that is a slice from the middle of another matrix. But to me it is just a matrix, so I would expect to call the same function to deal with it. I think some OO glue could deal with this, but I don't know what functions are involved.
Tamas
Liam