KMath: a Kotlin mathematics library that grew past the NumPy idea

The NumPy comparison was dropped on purpose

The README opens by saying KMath could be pronounced as key-math, and that the Kotlin Mathematics library was initially intended as a Kotlin-based analog to Python's NumPy. Then it says what happened next: the authors found that Kotlin is a much more flexible language and allows superior architecture designs, so in contrast to numpy and scipy the library is modular and has a lightweight core. The numpy-like experience is available, but not from this repository. It lives in a separate extension module called kmath-for-real. That reframing matters, because a lot of the design decisions in the library look strange until you understand that the target is not to clone a Python library but to build a mathematics API that suits Kotlin. The non-goals section makes the same point explicitly: being like NumPy was the original idea, but the project decided it could do better in API.

The three stated goals, and the four things it refuses to do

The goal section is short and worth quoting in substance. The library aims to provide a flexible and powerful API to work with mathematics abstractions in Kotlin multiplatform, covering the JVM, JS, Native and Wasm targets. It aims to provide basic multiplatform implementations of those abstractions, explicitly without significant performance optimization. And it aims to provide bindings and wrappers for popular optimized platform libraries. The non-goals follow the same structure. It will not provide the best performance out of the box, because specialized libraries exist for that and the project only offers API wrappers for them. It will not cover all cases immediately and in one bundle, since everything is modularized and features are added gradually. And it will not provide specialized behaviour in the core, because the API is made generic on purpose, so you need to specialize for types such as Float64 in a separate module.

Stability is a per-module property, not a per-library one

This is the most unusual thing about KMath and the thing to check before you depend on it. Different modules provide different features with different API stability guarantees, and although all core modules are released with the same version number, they carry different API change policies. Four levels are defined. PROTOTYPE means no compatibility guarantees at all: any method or class in those modules could break at any moment, and if you use one you should pin the exact version. EXPERIMENTAL means the general API is decided but some changes are still possible, with volatile parts marked by annotations such as UnstableKMathAPI. DEVELOPMENT means breaking changes follow semantic versioning, so they can appear in minor versions but not in patch versions, and the API is protected by the binary-compatibility-validator tool. STABLE means the API has stabilized and breaking changes are allowed only in major releases. A single dependency on the library can therefore pull in code at three different levels of promise.

The core is generic algebra, and speed comes from other modules

kmath-core is the foundation and it is marked DEVELOPMENT. Its feature list is the clearest picture of what the library actually is: algebraic structures like rings, spaces and fields in the algebras area, many-dimensional structures and operations on them, basic linear algebra operations such as sums and products backed by the Space API along with more advanced ones like matrix inversion and LU decomposition, one-dimensional structures in buffers, domains, automatic differentiation, parallel linear algebra, and big numbers. There is also an expressions feature, described as writing a single mathematical expression once and then applying different types of objects to it by providing a context, usable for high performance calculations and for code generation. The performance story sits elsewhere. The repository lists dedicated backend modules for EJML, ojAlgo, nd4j, multik, symja, tensorflow, viktor and kotlingrad, plus specialized modules for real numbers, tensors, statistics, geometry, functions, optimization, histograms and dimensions. The generic core plus pluggable backends is the architecture; the NumPy-style single fast array is what this deliberately does not give you.

A dozen backend modules means a dependency decision, not just an import

Look at the module list in the repository and the shape of the decision becomes clear. There is kmath-core, kmath-commons, kmath-ast, kmath-complex, kmath-coroutines, kmath-dimensions, kmath-functions, kmath-geometry, kmath-histograms, kmath-memory, kmath-optimization and kmath-stat, and then the accelerator modules kmath-ejml, kmath-multik, kmath-nd4j, kmath-ojalgo, kmath-symja, kmath-tensorflow, kmath-tensors and kmath-viktor. Choosing a backend is a real decision with real consequences, since each brings its own JVM library and its own performance characteristics, and the wrapper modules are what the project calls API wrappers rather than reimplementations. A couple of module statuses are worth noting. The benchmarks module is marked DEPRECATED, and kmath-ast, which carries the expression language and its parser along with the dynamic MST to JVM bytecode and JS compilers, is EXPERIMENTAL, as is kmath-commons. The kmath-complex module, covering complex numbers and quaternions, is still at PROTOTYPE level, which means no compatibility promises at all.

Jupyter, notebooks and the research pedigree

The badges and the surrounding organisation give the project its character. It is a JetBrains Research project, with a Zenodo DOI badge for citation, a Gradle build badge, and a Maven Central badge for the space.kscience group, where the core module is published as space.kscience:kmath-core. The documentation site lives at sciprogcentre.github.io/kmath, and the project has an examples directory with a README, a build file, a notebooks folder and a source folder, plus a dedicated kmath-jupyter module, which tells you notebooks are a first-class use case rather than an afterthought. The publications list reinforces that this is research software: two articles on context-oriented design, an ACAT 2019 conference paper, a KotlinConf 2019 talk about using Kotlin for science, a Joker 2021 architecture talk in Russian with an English version, and a seminar on the tensor API. The expression and context-oriented design work is the same idea showing up in both the code and the writing.

Where to get it, and what the maintenance record says

The README does not give an install command, so the practical answer is that the artifacts are published on Maven Central under the space.kscience group, with the core module published as space.kscience:kmath-core, and the project is a Gradle build with a settings file, a gradlew wrapper and a gradle.properties, so a consumer adds it as a Gradle dependency in the usual way. The maintenance record is uneven, and that is worth weighing. The repository is not archived and the last push was on 2026-10-07, the same day as the v0.6.0 release, with v0.5.0 in January 2026 and v0.3.1 in May 2023. So there was a long quiet stretch and then recent activity, and the project describes itself as requiring a lot of additional work, with the most important thing it needs being feedback about which features are required most. The licence is not classified by GitHub, so check the license directory in the repository before you ship anything that depends on it.

Editorial conclusion

KMath fits a Kotlin team writing cross-platform scientific code that wants one API across JVM, JS, Native and Wasm and that is willing to choose a backend module for speed. It does not fit someone who wants a drop-in NumPy, since that is an explicit non-goal, and it does not fit a project that cannot tolerate prototype-level modules in the dependency graph. Verify first which modules your use case touches and what maturity each one carries, because kmath-complex is prototype level while kmath-core is development level, and pin the version of any prototype module you depend on.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SciProgCentre/kmath on GitHub