Re: Matrix or array operations library

[Daniel Llorens]

> On 29 Dec 2018, at 00:16, John Cowan <address@hidden> 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>        address@hidden <mailto:address@hidden>
> Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
>     --Calvin, giving Newton's First Law "in his own words"
>