<@U8AT4H5K7> I am making a KMath adapter for Mutik...

# mathematics

[altavir]

@Pavel Gorgulov I am making a KMath adapter for Mutik (so one can use Multik internals with KMath API). There are some questions.

[altavir]

https://kotlin.github.io/multik/multik-api/org.jetbrains.kotlinx.multik.api/dnarray.html builder seems to be a little bit strange. It takes linear index instead multi-index. It makes the index useless because one needs to translate it to multi-index to actually create a shaped tensor

[altavir]

mk.zeros<T, DN>(shape, type)

seems to break the system since actual dim type does not correspond to explicit type and could not be cast

[Pavel Gorgulov]

Sorry for not answering for a long time, I was on vacation.
1. We will fix this point in 0.1.1
2. I will check this moment, I remember exactly that there was such the problem and I tried to fix it.

[altavir]

All in all, I've finished initial Multik wrapper: https://github.com/mipt-npm/kmath/blob/dev/kmath-multik/src/main/kotlin/space/kscience/kmath/multik/MultikTensorAlgebra.kt. Some operations from @Ролан’s API I am not sure how to implement correctly. But all in all it seems to be working like other algebras. Any comments are welcome.

[Pavel Gorgulov]

thanks
I’m researching this right now

[altavir]

I've also added some benchmarks (not that I believe they mean something. Multik-default gives the same result as kmath-core for simple operations. I have not checked if native optimizations are enabled.

[Pavel Gorgulov]

Simple operations are implemented only on the JVM side and work on primitive arrays, so there shouldn’t be a significant difference there.

[altavir]

Indeed, for dot product it gives a significant speedup

[altavir]

I think I will change Multik wrapper a bit so it do not use extensions, but access underlying operations directly so one could adjust which operation manager to use in which case.