<@U0BN58B38> I'll take a look at Koma again. One o...
# datasciencet
thomasnield
09/25/2018, 3:58 PM@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
k
kyonifer
09/25/2018, 5:58 PMI’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
09/25/2018, 5:59 PMIf 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.
t
thomasnield
09/25/2018, 6:02 PM@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.
k
kyonifer
09/25/2018, 6:07 PMAgreed— 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
09/25/2018, 6:15 PMOn 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
09/25/2018, 6:16 PMThe 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
09/25/2018, 6:18 PMOn kotlin/native I’m guessing cblas will beat most things, with the possible exception of expression templates like eigen in certain situations
t
thomasnield
09/25/2018, 6:32 PM@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.
k
kyonifer
09/25/2018, 6:40 PMSure— 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
09/25/2018, 6:42 PMHowever, 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
t
thomasnield
09/25/2018, 7:01 PM@kyonifer will do
9 Views