> Doesn't slib include pure-scheme matrix algebra and fft already?
>
> To do anything fast nowadays you need gpu acceleration, and I'm not sure
> it's easy to rewrite from scratch. So the potential srfi would need to not
> just include all the functions, but possibly support different backends,
> i.e. pure scheme, blas, gpu-blas, etc.
>
> I wonder if that would be really a good thing to include in the language
> itself (even if -large). But I'm not an expert by no means.

Fully agreed.

For workaday array/vector support in Scheme: Per, Marc, John and
possibly others have written several SRFIs.

For the heavy lifting and fancy math, gobs of brainpower and R&D dollars
have gone into things like CUDA, BLAS, Torch, TensorFlow, R and
Matlab/Octave. There is no conceivable way we can approach that level of
features and performance from scratch. "If you can't beat them, join
them" would be the winning move here :)

For prior art on multi-backend matrix stuff that integrates into Lisp,
look into Clojure's core.matrix and Incanter.

One thing that's easy to forget in these discussions is storage formats.
It's not that useful if you can't ship matrices from those common
packages into Scheme and out again. People who are accomplished with
this stuff won't want to use Scheme as their only tool. We should have
effortless compatibility with established formats.

At some point, standard network protocols will probably emerge for
shipping ML/statistics batch jobs to GPU clusters and getting out the
results. When they do, we should jump in.