Vec[N] - Medium term review

[Quafadas]

I've been using Vec[N] for a couple of months. Here is some feedback for discussion

Things I love:

• Cross platform! Running the numerics backend or frontend, depending on where makes most sense for the user is really cool.
• convience and clarity. It's wonderful that the extension methods are so clear, and there's very little complicated abstraction
• The clarity of the design, makes it very easy to contribute to. I think this is the killer feature.
• using sbt typelevel makes it easy to solve some issues around docs, tests, cross platform

Things I'm not clear about;

Performance - I want to try and benchmark some operations more properly

The big thing I struggled with, and want to explore, is the mental overhead of the types.

One of things I struggled with, is that if I have an Array[Double] I already have a great data structure, for numeric applications. As Vec[N], is not an industry standard datastructure, I found that transforming into a Vec[N] makes my mental model, less clear. It's also imposes overhead when I want to move from "numerics" back to other modeules of the program.

I think the jury is still out, on whether scala's type system can really support vector operations at the typelevel. Many operations I ran into which would have been easy in a matlab / julian sort of environment, were greatly complexified by the types. I note It seems to be always "possible", via dependant typing, etc. Whether it can be made user friendly enough to be desirable, I think is the open question.

So taking a step back, the things I think I'd want are;

• Make the extension methods operate on platform native arrays. i.e. Array[Double] and 'Float64Array`.
• Make each implememtation platform independant. This should allow plugging into native libaries, for truly native performance.

I think these changes may also have the benefit of making experimentation / migration easier. Someone wanting to try it out, would need only to add the dependancy and then they are off (in the platform of their choice). No refactoring to be able to drop into an existing codebase (thast uses Array[Double]) for example.

vecxt** https://github.com/Quafadas/vecxt explores this idea. Conceptually, I think it sits between NArray (which is a dependancy it has) and Vec[N]. Vec[N] does more in the typesystem.

I think one could build Vec[N] on top of a vecxtlike concept, but the other way around might be hard.

My questions on discord explored, whether it woudl be possible to dispatch the extension methods correctly, without unifying the type system, in the way that NArray does. I concluded, that it was not possible, and that NArray is a really cool piece of work :-).

** right now I can't get it to build in CI. Seems to work locally though.

[dragonfly-ai]

Thanks for the review! To address your points one by one:

"Performance - I want to try and benchmark some operations more properly"

Benchmarks sound great! I wish these were easier to accomplish for Scala cross platform libraries, but so far the approach toward optimization has focused on eliminating abstraction (no wrappers or inheritance on vector types); consolidating memory (matrix data lives in a 1d Array); and drilling down to native functions wherever possible (copying vectors delegates to native system calls that rely on SIMD capable hardware). We may have neared the limit of this approach, though, and ought to measure and test to see further improvements. For example, nothing in SLASH currently relies on any loop unrolling, where it probably could.

As for the mental overhead of the types, "... if I have an Array[Double] I already have a great data structure, for numeric applications. As Vec[N], is not an industry standard data structure ..."

I'll try to improve the documentation to reduce these kinds of type confusions, but in fact, Vec[N] is just an alias for Array[Double] on JVM and Native while in JavaScript, it's an alias for Float64Array.

To improve interoperability with other libraries, I've just added the extension method:

inline def asNativeArray: NArray[Double] = thisVector.asInstanceOf[NArray[Double]]

This should look cleaner than calling asInstanceOf[NArray[Double]] and also incur no performance costs.

Maybe, to reduce mental overhead, we can just remember that the types: Vec[N] and NArray[Double] only exist at compile time.

In light of that thought the things you'd want, "extension methods (that) operate on platform native arrays. i.e. Array[Double] and 'Float64Array`" and for "each implementation (to be) platform independent. This should allow plugging into native libaries, for truly native performance." are, happily, already core features of NArr, and by extension SLASH!

I'm excited to see how vecxt evolves, and thanks for praising NArr!

Thanks also for making SLASH so much better!