Hi folks! We are happy to share with you a very first preview of Multik  — a library of multidimensional arrays we are working on. It provides Kotlin-idiomatic, type- and dimension-safe API for mathematical operations on arrays. API has two pluggable implementations in Kotlin/JVM and Native (via JNI), and they can be switched on the fly to get the best performance. Right now we are in the first alpha stage and we are dying for your feedback. Read more: https://github.com/Kotlin/multik

Is it possible to use custom types and operations in it or you are limited to primitives?

Yes, right now we are limited to primitives, since we use Critical for native code. But for the JVM, we may support other types in the future

I made a brief glimpse into both API and implementation. It is really interesting, because this design is exactly what I decided NOT to do after my experience with numpy. I would really like to discuss it in more detail. Also our test showed that direct native interface does not give any significant boost to performance by itself (without cache optimization and other things), so it would be also nice to discuss it. If you are interested, I can organize a JBR seminar on this.

I'm happy to discuss it, but I think it's too early to do it as a seminar.

A discussion meeting then.

@altavir could you please more elaborate on numpy vs commons-math approach? Do you mean API style or underlaying implemenations ?

Both. Numpy give a limited selection of ndarray components exposed by underlying C implementation. The operations on those structures are hard-coded for given structure. It means that you can't easily just add a complex number. You need to add it everywhere and add new operations for it for the top level structure. Also you can't add new operations because you need to "propagate" operations inside the ndarray (in order to know how to sum two arrays, you need to know how to sum it components). This appoach is easier to implement though. Later incarnations of Commons maths and Commons-numbers give another appoach. They define generic algebras separated from actual elements. So one cand define ndarray of everything if the appropriate algebra is supplied. In Java it looks rather cumbersome, but Kotlin scoped functions allow to do it with minimal syntactic overhead. Making it wokr with the same performance is really hard, but I think that we managed it in Kmath. What is more important, we managed to abastract away the inner strucurer of nd array, so one cat use kmath as a wrapper API for any external library. For example we can wrap multik, if it will provide superior performance.

Thank you for you answer, now I have some more topics to go through 🙂 I find your idea with context in kmath very interesting...

It is much harder to implement, but in the end I think it is better. And we managed to achieve the level of performance of numpy for simple operations without using native parts.

What I believe, what became important is interoperability/reuse with other libraries, e.g. integration with deeplearning. This is what makes numpy in Python world so powerfull, despite beeige efficient etc.. I can and use it everywhere. Also multiplatform/native can became a huge advantage....

Again, there are two different phylosophies. Numpy is universal because everything is based on numpy. You can't use something different. I do not think this approach could be used in Java/Kotlin ecosystem because we already have a lot of libraries using different data formats. Kmath is mostly a wrapper API (though it has its own default implementations), so it is fully compatible with existing libraries by design. Recently @Iaroslav Postovalov even added a binding for native GSL libraries. With the same API and automatic conversions. Also we have integration with another JBR product Viktor and ND4J (also thanks to Iaroslav). The documentation is very thin though (help needed here!). But again, it requires some boilerplate to define a proper context algebra and is much more sophisticated.

gsl libraries -> gnu scientific library

Nice! Looking forward to trying this out. Re: DSL/API design. Agree there is lots of room for improvement over NumPy. The J/K family of languages brought some interesting ideas to the table, and I think there are still unexplored areas for a type-safe DSL to contribute. Was recently reading an interesting comparison of index-based vs. index-free styles of array programming. Worth a glance if you haven't seen it: https://futhark-lang.org/blog/2020-12-28-futhark-and-dex.html

@altavir I think we'll talk then next year. At any time convenient for you.

I really like the gradual type system. Inference seemed to work well on the examples I tried. Have you thought about whether there is a good way of adding dimension types? It would be neat if it were possible to infer the length of each dimension. I think there might be a way to synthesize dimension types up to a fixed length, but maybe it is better to wait until if/when the language supports dependent types, instead of shipping an ad hoc shape system in the DSL. Minor issues I noticed, it seems like operators are asymmetric. Do you plan to support

operator fun Number.<op>(other: MultiArray<T, D>)

? Importing operators on demand with <Alt>+<Enter> gets a little tedious. Maybe there is an IDE/API solution to default to import on demand from the

org.jetbrains.kotlinx.multik.ndarray.operations.*

extensions. The IteratingNdArray extensions are a nice touch. I wonder if there is a way to inherit from iterable without clashing with the operator overloads, or some other language pattern that would avoid reimplementing the wheel here. Is the linear algebra API more or less stable, or what is the planned API surface? In particular, it would be helpful to to know if multik intends to support boolean arrays and the broader NumPy linalg API or just a subset of those features: https://numpy.org/doc/stable/reference/routines.logic.html https://numpy.org/doc/stable/reference/routines.linalg.html

Iterable won't work because plus operation concatenates them by default. We had to introduce our own structures because of that. The iterator itself is bad for primitive performance.

@altavir hi, got interested in kmath. How mature is it, only one change (readme) last three months and release is not 1.0? Can you do simple arithmetics (*/+-) and does it have things like PCA, Distances (cosine, euclidean etc)? The documentation is a bit lacking from what I see

@Hampus Londögård Kmath is in experimental stage and will be there for a while. It is a huge endeavor and currently we have only three people working on it when time allows. Also we are experimenting a lot with API (to use Kotlin features to their maximum), so I do not think the API outside core module will be stable in a near future. And of course the documentation is a huge problem. On the other hand, we do not implement everything from scratch and prefer to create connectors to already existing libraries, so implementations themselves are sound and the main point is that you can switch implementation at any moment without breaking the API. The geometry module is on the near TODO list (some things are already there, but major new features are planned). I think that at this moment it is better to work together than to create a lot of incompatible tools, so I would really appreciate if you could explain your case as an issue in the github and we can see if features are already there or if we need to implement anything new. And PR-s and new modules are always welcome. The detailed discussion could be done in #mathematics

@altavir thanks! That is sound, I'll join the #mathematics channel!👍

@breandan I tried dimensional types but settled on the current version. Yes, I plan to support operators for Number. There is one more annoying thing with operators - plusAssign, timesAssign and so on. These are inplace operators and don’t work with

var

. Alexander is right about Iterable. In addition, Iterable often returns list as a result, which is not suitable for us. API will expand. This applies in particular to linear algebra. Logical array support has not been discussed yet.

Makes sense, thanks for the info! I didn't look closely so not sure if it's possible to use NDArrays to index other NDArrays, but usually indexing has a specific semantics. For example, two equal length dimensions can be contracted without error, but may not produce a semantically valid result. This is the named tensor idea I mentioned which PyTorch recently added support for, perhaps you have already seen it: https://namedtensor.github.io/ Some possible notations:

nd1.contract(index){nd2}

,

(nd1*nd2)[index]

Re: Iterable. I've seen this pattern in other Kotlin libraries and it makes sense, although I wonder if there is a language solution to reduce duplication somehow.

Hah, I've actually done those named matrices four or five years ago, for completely different reason of course, I needed to name correlation matrices for multi-dimensional fits. The current implementation uses KMath Symbol instead of strings. Symbol was designed to designate variables in expressions, but it actually works fine for naming dimensions as well.