mpmath keeps arbitrary precision arithmetic in pure Python

A long history with a 1.x version that took a decade

mpmath is a Python library for arbitrary-precision floating-point arithmetic, and the main author is Fredrik Johansson. The site is mpmath.org, the licence is the New BSD License, and the release history in the README goes all the way back.

The dates matter for judging the project. Version 0.1 was released on 27 September 2007, 0.2 on 2 October 2007, and the 0.x line ran through 0.19 in June 2014. Then 1.0.0 on 27 September 2017, 1.1.0 in December 2018, 1.2.0 and 1.2.1 in February 2021, 1.3.0 in March 2023, and 1.4.0 on 23 February 2026 followed by 1.4.1 on 15 March 2026.

So the library is old, and the 1.x line is more than eight years old as of the latest release. That is a double-edged fact. On one side, the numerical algorithms behind the special functions have been refined and cross-checked for nearly two decades, which is the kind of maturity that matters more in a maths library than in most software. On the other, the 1.3.0 to 1.4.0 gap of nearly three years suggests a slow release cadence.

The credits list is a partial history of the Python numerical community, with Pearu Peterson, Ondrej Certik, Aaron Meurer, Tim Peters, Nike Dattani and many others among the contributors, and Fredrik's own work during summer 2008 was sponsored by Google as part of the Google Summer of Code, and his 2009 work by the American Institute of Mathematics under a National Science Foundation grant on L-functions and Modular Forms. The README also notes the disclaimers about those sponsors' views, which is an unusual and welcome bit of care in a project README.

The last push was on 2026-10-19, and the repository is not archived.

Pure Python, with gmpy as the speed lever

The performance story is the most important practical detail about mpmath, and the README states it plainly in the credits: credit also goes to the authors of the GMP library and the Python wrapper gmpy, enabling mpmath to become much faster at high precision.

That is the key design decision. mpmath is a pure Python implementation, which means the arithmetic is done in Python's arbitrary-precision integer type, and the algorithms are written in Python rather than compiled. Installing gmpy alongside it gives the library a compiled arbitrary-precision backend for the arithmetic itself, and the difference is substantial at high precision.

The pyproject.toml shows how this is optional rather than required. There is a develop extra and a tests extra, and the optional-dependencies section is where a gmpy-related extra would sit, alongside the tests extra that pulls pytest, numpy, packaging, pytest-timeout, matplotlib for Python below 3.15, pexpect, ipython and hypothesis, and the develop extra that combines the tests extra with pytest-cov, wheel and build.

For a library whose entire purpose is precision, that architecture is a reasonable trade. Pure Python means the algorithms are readable, and a numerical method you can read is a numerical method you can debug. It also means the library works anywhere Python works, and the pyproject.toml classifiers show a wide interpreter matrix: CPython 3.10 through 3.15, PyPy, and GraalPy, with a free-threading beta classifier for CPython.

The topic list on the repository matches the scope: complex-numbers, multiprecision, numerical-integration, numerical-methods, numerical-optimization, ordinary-differential-equations, plotting and special-functions.

The reference work is credited in the README too, with Wikipedia contributors, Abramowitz and Stegun, Gradshteyn and Ryzhik, and Wolfram Research for MathWorld and the Wolfram Functions site named as the main references used for the special functions implementations.

Installing and running the tests

Mpmath requires Python 3.10 or later versions, and the README says it has been tested with CPython 3.10 through 3.15, with PyPy 7.3.23 and with GraalPy 25.3. The pyproject.toml agrees with requires-python = '>=3.10', and the classifiers list 3.10 through 3.15 individually.

The install is the ordinary one:

pip install mpmath

Or from the source tree, pip install ., and the release is also available from the mpmath website and from the GitHub releases page, as well as from the Python Package Index. The latest development code is on GitHub, and the README points at the main documentation for more detailed instructions.

The build system in pyproject.toml is setuptools with setuptools-scm, and the version is declared as dynamic, which means the version comes from the git tags rather than being written in the file. The build requires setuptools 77 or newer and setuptools-scm 8 or newer.

Testing is pytest based. The unit tests live in mpmath/tests/ and are run with pytest, and there is a conftest.py at the top of the repository, along with a .codecov.yml for coverage reporting. The master branch is automatically tested on GitHub Actions, and the README points at the demo scripts in the demo directory as something worth looking at.

The demo directory is worth a look, because the file names describe the use cases: mandelbrot.py, manydigits.py, pidigits.py, plotting.py, sofa.py and taylor.py. That is a project shipping arbitrary precision as a general tool, from high precision digit extraction to fractal plotting and series evaluation.

The known problems section is unusually candid

Most library READMEs do not have a known problems section. mpmath's does, and it is the most useful part of the document for anyone deciding whether to trust a result.

The first entry is that some functions may return incorrect values when given extremely large arguments or arguments very close to singularities. That is a direct statement that the library will not warn you about a case it handles badly, and it is exactly the failure mode that matters in a numerical library.

The second is about rounding. Directed rounding works for arithmetic operations, and it is implemented heuristically for other operations, so their results may be off by one or two units in the last place even if otherwise accurate. If you are using mpmath for interval arithmetic or for error bounds, that caveat is the difference between a sound result and one that is nearly sound.

The third is IEEE 754 support. Some features are not available. Infinities and NaN are partially supported, there is no signed zero, and denormal rounding is not available at all. A library that does not have signed zero cannot represent the difference between positive and negative zero, which is a small thing until you divide by zero and expect a sign.

The fourth is thread safety. The interface for switching precision and rounding is not finalized, and the current method is not threadsafe. In a program that changes precision per thread, the global context switch will interfere with other threads, and the README says so directly.

Taken together, these are the constraints to design around. mpmath is a work in progress by its own description, and the numeric answer you get is usually right to far more digits than you need, but the last couple of digits are not guaranteed in the non-arithmetic paths.

Where mpmath is the wrong tool

The first limit is performance, and it is not subtle. The pure Python implementation is doing arbitrary-precision arithmetic in the interpreter, so a computation that a double-precision library does in microseconds can take orders of magnitude longer. If your problem does not need more than about 15 significant digits, mpmath is the wrong answer, and the standard library's math module or numpy will serve you better.

The second is that a general-purpose numerical library is not a substitute for a specialised one. mpmath's special functions are the reason to use it, and they are implemented in Python, which means they are not competitive with a compiled implementation for a routine workload. The README itself points at MPFR, pari/gp, MPFUN and other arbitrary-precision libraries as sources of documentation help, whose documentation the README credits as helpful for the algorithms.

The third is the thread safety caveat, which is worse than it sounds in a modern service. The precision context is a global, and changing it is not thread safe, so mpmath in a multi-threaded web worker needs either a lock or a design where each thread works on its own context, and the README says the interface for switching precision is not finalized.

The fourth is the release cadence and the age. The 1.3.0 to 1.4.0 gap was almost three years, and the README describes the project as a work in progress. That is fine for a stable numerical library whose algorithms have been checked for a decade, and less fine if you need a new function that appeared in the literature recently, or if you need the library to track a new Python release promptly. The build requires setuptools 77 and newer, which is a recent requirement, so the packaging does get refreshed, but the version numbers move slowly.

The fifth is the licence consideration, though here it is mild. The New BSD License is permissive: commercial use is fine as long as the copyright notice is kept.

Editorial conclusion

mpmath suits a Python project that needs more precision than a float can hold, or needs a special function that no standard library provides, and it is the wrong tool for routine work where double precision is plenty, because the pure Python arithmetic is not free. Before adopting it, check the known problems list, since directed rounding is only heuristic outside arithmetic and some IEEE 754 features such as signed zero and denormal rounding are not available at all. Verify first that you install gmpy alongside it if speed matters, because the README credits gmpy with making mpmath much faster at high precision.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. mpmath/mpmath on GitHub
3. Project website
4. README
5. Releases