Swift for Tensorflow has started to attract people with Data Science background to Swift, however, for the ecosystem to thrive there needs to be basic libraries other than Tensorflow. This brings up a couple of questions:

Should Tensorflow be the defacto matrix library? S4TF operations on CPU can be way faster than Python's Numpy, not sure why but some test I've done show that S4TF uses all the cpu cores while numpy used only a few. However, I am not sure if S4TF Tensors can be flexible enough, even when running on the CPU backend, for applications such as generic image processing. In other words, could you do anything that numpy can do with S4TF Tensors on the CPU?

Hard to say without knowing more about what you're doing, but this sounds mostly like NumPy is just using unoptimized (or poorly optimized) kernels in your use case.

They're not, but ShapedArray is pretty close to the right foundation that domain-specific libraries can wrap with additional functionality as needed, and is what I would recommend people interested in this kind of thing work with today.

Hey @scanon, thanks for the info. I have a couple more questions/comments:

Right now I see there are no methods / operators on ShapedArray, are there plans to implement a basic set of these?
You think that ShapedArray could eventually live outside the TF repo?
Is ShapedArray differentiable? I think a subset of its operations should be, just like Tensors.

The Swift for TensorFlow project doesn't yet have any plans to add math operations to ShapedArray. It is designed to be a multi-dimensional variant of Array with contiguous storage.

I think so :) It does not depend on TensorFlow.

You can certainly make APIs like subscript(_:) and init(shape:scalars:) differentiable, after conditionally conforming ShapedArray to Differentiable.

It's important to point out that we should be very conservative about defining math operations for the base "currency" type for numerical computing, because if we're not very careful, methods will invariably be added that are wrong for one or more domains of interest. Most numerical operations that are not truly universal should be defined via wrapper types (e.g. a Matrix wrapper would define linear algebra operations, and also enforce the constraint that the shape is rank-2). It then becomes critical to also have the minimal protocols that allow a user to convert between different wrapper views of the same underlying storage as needed.