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

[Liam Healy]

On Fri, Apr 11, 2008 at 10:56 AM, Tamas K Papp <tpapp at 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