I ll take a look at Koma again One of the reason

Question

< kyonifer> I ll take a look at Koma again One of the reasons I ve been playing with ojAlgo quite a bit is because it has some applied API s linear integer optimization as well as a neural network that provides good bang for my buck dependency wise However there is no reason why this couldn t be done with Koma either P

kyonifer · Answer

I ve recently refactored koma to a set of modules with koma core having the data containers and refactoring the limited plotting and logging stuff I have to koma logging and koma plotting I did so with the explicit goal of having more than just linalg support in the future so as you mentioned perhaps having koma optimization would make sense

kyonifer · Answer

If there s one obvious choice for how to implement that on a particular platform I don t think it necessarily needs to be pluggable either I was going to look at using Apache commons for the jvm implementation but i can take a look at ojalgo as well

thomasnield · Answer

< kyonifer> I would definitely give ojAlgo a look as it claims to be one of the fastest JVM linear algebra implementations However I find its type hierarchy kind of confusing so if we can abstract that away that would be awesome That s kind of what I m trying to do with okAlgo which I ll pivot from if it makes sense

kyonifer · Answer

Agreed if we can build a type hierarchy that makes the most sense and is the cleanest for kotlin and then implement it using the fastest backend on each platform I think that would be the ideal solution

kyonifer · Answer

On the jvm I think there will be a split between libraries that call out to native and those that are pure java with the native ones winning when matrixes are large and the pure ones winning for smaller ops so it probably makes sense to support both pluggably since there isn t a clear winner

kyonifer · Answer

The latest bench I could find that included native and ojalgo seem to support that with mtj winning <http lessthanoptimal github io Java Matrix Benchmark runtime 2015 07 XeonQuad > not sure if there s a more up to date bench with native blas in it the 2018 charts don t seem to

kyonifer · Answer

On kotlin native I m guessing cblas will beat most things with the possible exception of expression templates like eigen in certain situations

thomasnield · Answer

< kyonifer> keep in mind too that it might be helpful for devs curious about the library that they may want to clone Koma and build it Having it easily be available as a pure JVM codebase possibly might make it easier for folks to explore without bindings Then again I have never done bindings before with a C lib so it might not be as bad as I image for compilation

kyonifer · Answer

Sure the buildJvm gradle command should build only kotlin code and depend only on maven artifacts One of the produced artifacts koma core ejml should be a pure jvm library for people who need pure java and don t want to mess with blas libs If you have any issues with getting that to work out of the box without anything installed outside of a jdk and an internet connection let me know The ci runners look okay on Mac Linux and Windows at least

kyonifer · Answer

However ojalgo may be a better choice than ejml for the pure jvm path I wasn t aware of the former when I was wrapping ejml

thomasnield · Answer

< kyonifer> will do