Re: Matrix or array operations library

[Daniel Llorens <daniel.llorens@bluewin.ch>]

> On 29 Dec 2018, at 00:16, John Cowan <cowan@ccil.org> wrote:

> If array objects don't have an offset (the index in the backing store of the [0,0, ... 0] element), you can't do arbitrary translations, unfortunately.  If Guile doesn't have that, it should.

It does; I just forgot to mention it. make-shared-array accepts any affine function of indices. There's even a function to get at the offset directly  (shared-array-offset). All this is in the manual and has been in Guile for a long time.

> Layering a Guile compatibility mode over SRFI 122 might be a Good Thing.  Arrays there allow arbitrary affine transformations of the indices, provide lazy elementwise mapping (you can get eager mapping by composing mapping with copying), and have fast paths for arrays of up to 4 dimensions.  Read-only and read-write arrays defined by arbitrary getter and setter functions are also provided, and work exactly like storage-based arrays.  SRFI 122's only major limitation, which IMO is not a serious one, is that it doesn't handle 0-dimensional arrays (with one element) or degenerate arrays with non-positive dimensional ranges (with zero elements).  The code is in Gambit Scheme, but translating it to portable Scheme is an easy matter (I just haven't gotten around to it).  The main Gambit-specific dependency is define-macro (non-hygienic) macros, but nothing very bad is done with them.

Rank 0 arrays and empty arrays happen all the time if you work with arrays. I think it would be annoying to have to look out for special cases.

To be honest I find it strange that SRFI-122 doesn't support those you since you shouldn't need to do anything special (Guile supports them for free, other than a special case in the read syntax iirc). 

Guile only has the type and a few low level functions. My library guile-ploy provides arbitrary arity and arbitrary rank rank extension on top of Guile, plus a bunch of array functions, including full APL-style slicing. Still no lazy mapping, that would be nice to have. You probably want operator overloading as well.

One thing that is needed is a linear range generator of some kind, like a:b in Python. It's not enough to provide a procedure for this, since the slicing function must be able to recognize this linear range in order to avoid copying. For instance x[a:b], should produce another array with different strides, not a copy and not a lazy map either. In guile-ploy this is written (from x (range a b)), where (range a b) is a special type. In guile-newra this linear range is one of the basic vector types (along with vectors, bytevectors, and srfi-4 vectors). Does srfi-122 provide something like this? I suppose if you have lazy maps the linear range can be done with those and then the slicing function can be written to recognize it.

I shall try and have a look.

	Daniel


> There is a post-SRFI fork at https://github.com/gambiteer/srfi-122/ <https://github.com/gambiteer/srfi-122/> which will fairly soon become an updated SRFI.
> 
> -- 
> John Cowan          http://vrici.lojban.org/~cowan <http://vrici.lojban.org/~cowan>        cowan@ccil.org <mailto:cowan@ccil.org>
> Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
>     --Calvin, giving Newton's First Law "in his own words"
>