Well, SRFI 164 does integrate with SRFI 4 (or 160), assuming you allow uniform vectors as "gectors".
To allocate an f32 N*M matrix, one can do:
(array-reshape (make-f32vector (* N M)) (vector N M))
I should have been clearer. SRFI 122 guarantees that the user can create arrays whose elements are limited to one of the SRFI 160 vector types (that is, SRFI 4 + complex64 + complex128). However, it does *not* guarantee that the elements are stored compactly: they might be stored in an ordinary Scheme vector. On the gripping hand, it guarantees that arbitrary user-defined storage objects with the correct interface can store an array of the first kind (for example, a hashtable paired with a default value, which would serve as a compact representation of a sparse array). SRFI 164 provides none of these guarantees to the user: what types of storage objects are available is determined by the implementation.
> 6) SRFI 122's transformation procedures are affine, which means they are very efficient. SRFI 164 provides general transformations, which can of course be written on top of SRFI 122, but aren't provided by default.
SRFI 164 includes share-array from SRFI 25, which which requires an affine transformation function.
Yes. I should have said that while both SRFIs provide nearly-free affine transformations, SRFI 164 also provides a procedure for doing arbitrary transformations, whereas SRFI 122 does not.
https://github.com/gambiteer/srfi-122
I remember now that you told me this before. Please do, and I can substitute 122 bis for 122 on the ballot when the time comes.
The procedures interval-for-each, interval-cartesian-product,
array-outer-product, array-tile, array-assign!, and array-swap! have
been added.
APL-style array-inner-product with two functions would be a Good Thing to have as well. Of course the arguments would have to conform: that is, the bounds of the last dimension of the left operand must be the same as the bounds of the first dimension of the right operand. This collapses nicely to the vector inner product where the functions are * and +.
array->vector was another routine I was considering, but hadn't decided
if it was worth adding.
It makes sense to me.
So I don't know when this vote will take place,
I don't either, but surely you'll beat me to it. I have a lot of pre-SRFIs to implement.
but I have time in the
next month or so to devote to proposing and (hopefully quickly)
finalizing a better version of SRFI 122.
Excellent!
> 5) SRFI 122 provides more convenience functions than SRFI 164, including
> in particular a lazy array-map operator that, given an array and a
> mapping function, provides an array of the second kind.
I find the convenience procedures in the section "Common transformations
on Bawden-style arrays", which define to be the most important for
practical applications.
SRFI 164 has those as well: see above.