On 7/28/19 8:24 AM, Lassi Kortela wrote:

> The performance and interoperability implications of any array API are quite complex because the most prominent use of arrays now is machine learning and other statistical work on huge datasets. That brings concerns like sparse arrays, float representations, GPU acceleration, interoperation between things like R, Matlab, TensorFlow, Torch, BLAS and Clojure's core.matrix. For ML/stats applications, Scheme would ideally re-use a highly optimized array representation and routines from one of these industry-standard frameworks. I would hesitate to comment on how to take all this into account since I'm not well versed in it.
(I looked a bit at clojure.core.matrix.  Seems quite powerful,
but I found it a bit overwhelming and lacking in elegance,
perhaps because the API is documented in alphabetical order,
rather than by concept/category.)

One issue with clojure.core.matrix is that it mixes in the same package
general rank-N array procedure with more specialized rank-2 matrix procedures,
SRFI 164 is a not complete array/matrix library, but it attempts to
provide flexible building blocks that are boh useful for applications
programmers and that could be built on by library designers.

The clojure.core.matrix API support using different "implementations".
SRFI 164 supports this partly with the concept of "generalized vector"
and "underlying vector": A Clojure "implementation" corresponds to a
generalized vector type. You can use array-reshape on any generalized vector.

For things like sparse matrices the build-array procedure provides the
necessary primitive.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/