Geomstats: Riemannian geometry and statistics on manifolds, with NumPy, Autograd or PyTorch backends

The problem Geomstats solves: Euclidean assumptions on non-Euclidean data

Averaging rotation matrices by summing them and dividing by n produces a matrix that is not a rotation. Interpolating between two shapes by linear blending can produce a shape that is not in the shape space. Fitting a Gaussian to covariance matrices ignores that the space of symmetric positive definite matrices is a curved manifold, not a vector space. These are the failures Geomstats is built to address. The repository describes itself as a Python package for computations, statistics, machine learning and deep learning on manifolds, and the two top-level modules reflect that split: geometry for the differential geometry objects, learning for the statistics and learning algorithms that operate on data living on them. The intended user is not a general application developer. It is someone who already knows that their data has a geometric structure and wants the exponential map, the logarithm map, the geodesic and the Frechet mean computed correctly instead of approximated. The README points to examples and notebooks directories for getting started, and links an introductory video and slides describing how the package is built, which is consistent with a library aimed at people who want to understand the construction, not just call it.

How the geometry and learning modules are separated

The architecture visible in the README is a two-module split. The geometry module implements differential geometry: manifolds, Lie groups, fiber bundles, shape spaces, information manifolds, Riemannian metrics, and more. The learning module implements statistics and learning algorithms for data on manifolds. That separation matters in practice because it means the manifold object and the estimator are independent choices. You pick a manifold and a Riemannian metric from geometry, then pick an estimator from learning that consumes it. The README also names specific submodules that were added over time: a shape module announced in 2025 with an accompanying ACM TOMS paper on learning from landmarks, curves, surfaces, and shapes, and an information_geometry module announced in 2023 with a paper on parametric information geometry. Those two are the clearest evidence of where the project's active development has gone. If your problem is landmark-based shape analysis or a parametric family of probability distributions, the README directs you to those directories by name rather than leaving you to search the general manifold list.

Three backends, and what that choice costs you

The README states that users can choose between backends: NumPy, Autograd or PyTorch. This is the single most consequential design decision for an adopter, and it is stated in one sentence. NumPy gives you the numerical path with no automatic differentiation. Autograd gives you gradients for the manifold operations. PyTorch gives you the deep learning path, which is what makes the deep learning claim in the package description concrete rather than aspirational. The cost is that the backend is a user-facing choice, which implies the code you write has to be written against one of them, and the README does not present a compatibility matrix showing which learning algorithms exist on which backend. The repository's coverage badges are listed separately for np, autograd and torch, which tells you the maintainers track coverage per backend rather than as a single number. That is a signal worth reading carefully: per-backend coverage tracking exists because the backends are not identical in what they support. Before committing, check the learning module for the specific estimator you need and confirm the backend you intend to use is the one it is implemented against.

Getting it running: install and the first objects to construct

The README does not include a pip install line in the material supplied here, so the installation command is not something that can be quoted from it. What the README does give is the PyPI version badge, which confirms the package is distributed on PyPI under the name geomstats, and the version history shows 2.8.0 released on 2024-09-09, following 2.7.0 and 2.6.0 in 2023. The practical entry points the README names are the examples directory, the notebooks directory, and the documentation site at geomstats.github.io. It also links a Binder badge, which means you can open the notebooks in a hosted environment without installing anything locally. That is the lowest-friction way to evaluate whether the geometry module's abstractions match how you think about your data. The README additionally points to the information_geometry subdirectory for that specific topic. For anyone deciding whether to adopt, the order that makes sense is: run a notebook through Binder, find the manifold closest to your problem in the geometry module, then check whether the learning estimator you need exists for your backend.

Where Geomstats is the wrong tool

If your data is Euclidean and your pipeline is already a scikit-learn or PyTorch stack, adding Geomstats introduces a manifold abstraction you do not need. Every operation becomes a method on a manifold object with a metric attached, and you pay the conceptual cost of tangent spaces and exponential maps for no benefit. The second case is harder to see: a problem that is nominally geometric but where the relevant manifold is not implemented. The README lists manifolds, Lie groups, fiber bundles, shape spaces, information manifolds and Riemannian metrics as categories, not as an exhaustive catalogue. If your structure is not in that catalogue, you are implementing the geometry yourself, and at that point you are using Geomstats as a template rather than a library. A third case: if you need production-grade numerical guarantees on a specific manifold, the README offers no accuracy or performance claims, and the per-backend coverage badges are the only quality signal present. Treat the library as a research implementation whose correctness you should validate against a known closed-form result on your manifold before trusting it in a pipeline.

How it compares to writing the geometry yourself or using a general autodiff library

The realistic alternative is not another manifold library. It is either implementing the geometry in NumPy or PyTorch directly, or using a general automatic differentiation library and expressing the manifold operations as constrained parameterisations. The difference in approach is where the mathematics lives. With Geomstats, the manifold, its metric, and the exponential and logarithm maps are first-class objects provided by the package, and the learning algorithms in the learning module are written against that interface. With a general autodiff library, you have gradients but no notion of a geodesic, so the Frechet mean, parallel transport and the manifold-valued statistics have to be derived and implemented by you. The trade is explicit: Geomstats gives you the geometric vocabulary and the estimators that use it, at the cost of adopting its manifold interface and its backend choice. Rolling your own gives you total control and no interface to learn, at the cost of reimplementing mathematics that has published references behind it. The README's citation section lists four papers, including a JMLR 2020 paper and a 2023 Foundations and Trends in Machine Learning article that the README describes as going from basic theory to implementation with Geomstats. That is the documentation of record for the design, and it is more substantial than the README itself.

Licence, maintenance and what the release cadence tells you

Geomstats is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own code, and it is the same category as NumPy and PyTorch, so there is no licence friction in combining them. This is not legal advice; read the LICENSE file in the repository for the operative text. On maintenance, the visible signals are the release dates: 2.8.0 in September 2024, 2.7.0 in August 2023, 2.6.0 in June 2023. The last push recorded on the repository is 2026-08-21, and the repository is not archived. The gap between 2.6.0 and 2.7.0 was about two months, then roughly a year to 2.8.0, which is a slower cadence than a library on a fixed release train. The NEWS section shows module-level additions in 2023 and 2025 with peer-reviewed papers attached to each, which suggests the project's development is driven by research output rather than by a support roadmap. Upgrade cost is therefore tied to which modules you use: if you depend on the core geometry and learning modules, expect the interface to be stable across minor versions, but if you build on the shape or information_geometry modules, read the release notes for those before upgrading, since they are the areas where the project has been adding surface area.

Editorial conclusion

Adopt Geomstats if your data genuinely lives on a manifold (rotations, shapes, SPD matrices, probability distributions) and you want the metric, exponential map and Frechet mean handled by a library rather than by your own derivation. Do not adopt it as a general-purpose deep learning framework or as a drop-in replacement for Euclidean scikit-learn pipelines; the geometry module imposes a vocabulary of manifolds, metrics and tangent spaces that your data has to satisfy. Verify first that the specific manifold you need is implemented in the geometry module and that your chosen backend (numpy, autograd or torch) is the one the learning algorithm you intend to call actually supports, since the README presents the three backends as a user choice rather than a guarantee that every algorithm is available on all three.

Official sources

1. geomstats/geomstats on GitHub
2. License: MIT
3. Project website
4. README
5. Releases