Following the week of mathematical releases in Kot...
# mathematics
a
Following the week of mathematical releases in Kotlin, I am happy to present KMath release 0.2.0: https://github.com/mipt-npm/kmath/releases/tag/v0.2.0. The release contains numerous new features and API fixes as well as new pacckage name (
space.kscience
) and a completely new understanding of library aims. KMath does not want to follow numpy path and provide bindings for a single implementation of nd-arrays and numerics. Instead, we are working on a Kotlin-first API, that allows us to better tap into the kotlin lagnuage potential and allow to create the same or similar API to different existing libraries, so one could easily switch implementations withot a lot of changes in the code. Also we provide simple multiplatform implementations for people, who do not need super-optimized performance. Those basic implementations are thereby referenced as kmath-core to avoid confusion with library bindings like kmath-commons, kmath-ejml, kmath-viktor etc. The important feature of the new release is the new documenation and stability policy. Ecch module has a Maturity level shown in the documentation: • PROTOTYPE - both idea an the implementation may change. • EXPERIMENTAL - we have an idea how it should look like, but implementation could change in minor versions. • DEVELOPMENT - API compatibility between monitor versions is controlled via https://github.com/Kotlin/binary-compatibility-validator. • STABLE - no module has reached this stage yet, but we plan to enforce production-ready stability guarantees. New documentation plugin allows to maintain the list of module features. Here is the list of key feature modules: • kmath-core Core classes, algebra definitions, basic linear algebra, nd-structures, expressions etc. • kmath-commons Bindings for Commons-math library. • kmath-complex Complex numbers and quternions (separated from core in this release. • kmath-nd4j ND4J bindings for nd-structures implementation. • kmath-ejml EJML bindings for linear algebra implementatiion. • kmath-viktor JetBrains Research Viktor bindings for real-valued nd-structures. • kmath-histograms Univariate and multivariate histograms. • kmath-ast MST (mathematical syntax tree) definition, JIT expression compilation with ASM on JVM and JS interpreter on JS. Symbolic algebra. • kmath-kotlingrad Automatic differentiation via MST and kotlingrad library. The significant part of the release is done by @Iaroslav Postovalov. I would also like to thank a lot of people, including @breandan, @Peter Klimai, @elizarov , @Ролан, @Aleksei Dievskii, @roman.belov, @Pavel Gorgulov and numerous others (I can't remember them all, we need a list), for discussions and contributions. The project is supported by the JetBrains Research.
🎉 12
The documentation and examples are still a sore point, so contributions are welcome.
The release is (at least should be) available via https://repo.kotlin.link/. We will add MavenCentral publication as soon as the deployment bugs are fixed.
Now on maven central as well. I thought it will kill me.
🫂 4
z
Great news for Data Science ecosystem!
a
Thanks. This is still a research work, and I hope that together we can understand how to do things better, using full potential of Kotlin.
MavenCentral deployment seems to be broken. Thanks @Aleksei Dievskii for the info
Maven-central publication should be fixed in 0.2.1 (no principial changed, only publication. But the 0.3.0 version is comming soon with breaking changes in Algebra interface (@Aleksei Dievskii and @Ролан hard pressed me to pay more attention to therminology soundness).
🤔 1
Actually I could not do fully idiomatic algebras, but at least I moved number operations to
Field
. They are no longer present for Space and Ring. PR is here: https://github.com/mipt-npm/kmath/pull/219
e
Our current prototype for multiple receivers has morphed into support for “contextual functions” (new name for the concept) and they do support contextual operators, e.g.: https://gist.github.com/elizarov/b0496d4bb333172aa37b093c1f108fce
a
@elizarov Thanks a lot. It could really simplify both the code and user experience. I plan to remove parts algebra hierarchy propagation in future and replace it with static dispatch on multiple receivers. Of coures, we will need to clear the dispatch rules since there could be complex cases.