[Gsll-devel] What is needed to fix matrix views?
Tamas K Papp
tpapp at Princeton.EDU
Fri Apr 11 14:56:36 UTC 2008
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.
> 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).
> 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.
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.
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
More information about the gsll-devel
mailing list