Measurements.jl: a number that carries its own error bar

What the package is for

The package is described as an error propagation calculator and library for physical measurements, supporting real and complex numbers with uncertainty, arbitrary precision calculations, operations with arrays and numerical integration.

The problem it solves is stated plainly in the introduction. Physical measures are usually reported with an error, a quantification of the uncertainty of the accuracy of the measurement. Whenever you perform mathematical operations involving these quantities you also have to propagate the uncertainty, so that the resulting number will have an attached error quantifying the confidence about its accuracy. Measurements.jl relieves you of that hassle when performing mathematical operations involving them.

The method used is the linear error propagation theory, applied to linear combinations.

The library is written in Julia, and the README makes a point that is easy to miss: when used in the Julia interactive session it can serve as an easy-to-use calculator. That is a real use case, because typing 4.5 ± 0.1 in the REPL and seeing the propagated result is faster than doing the arithmetic by hand and hoping.

The primary language is Julia, the licence is MIT under the Expat License, the default branch is main, and the homepage is the stable documentation at juliaphysics.github.io/Measurements.jl. The recent releases are v2.14.1 from 2025-10-18, v2.14.0 from 2025-06-26 and v2.13.0 from 2025-06-14, and the last push was on 2026-09-22 with the project not archived. The original author is Mosè Giordano, and the tree carries a CITATION.bib, a NEWS.md and a Project.toml alongside src/, ext/, test/, benchmark/ and docs/.

The correlation handling, which is the interesting part

Most of the feature list is a list of things you would expect. Support for most mathematical operations in the Julia standard library and in SpecialFunctions.jl, involving real and complex numbers. Arrays of measurements with some linear algebra working out of the box. Arbitrary precision numbers with uncertainties, useful for measurements with very low relative error. Functions to calculate standard score and weighted mean. Parsing strings to create measurement objects. And the ± sign as an infix operator, described as syntactic sugar that makes the code more readable and visually appealing.

But one entry stands out, and it is the reason the package is worth using rather than merely convenient.

Functional correlation between variables is correctly handled, so x - x is approximately zero with zero uncertainty, x/x is approximately one, tan(x) is approximately sin(x)/cos(x), and cis(x) is approximately exp(im*x).

That is the difference between a number with a tag and a number with a value and a derivative. If you implement uncertainty propagation by tracking a single standard deviation per quantity and combining it with the usual root-sum-of-squares rule at every step, then x - x gives you the propagated uncertainty of x added to itself, which is not zero, and every such cancellation in your analysis leaves a residue of fake error. A measurement of a quantity that was measured twice and then subtracted should not be less certain than the measurement of the difference.

The approach is described in a paper, M. Giordano, 2016, Uncertainty propagation with functionally correlated quantities, arXiv:1610.08716, which is where the method comes from rather than being an implementation detail of the package.

The limitation is stated in the same breath, and it is a real one. A current limitation of the package is that it is not yet possible to define quantities related by a correlation matrix. So the package tracks correlation that arises from the algebra itself, but you cannot declare that two independently measured quantities are correlated by some external process.

That distinction matters in practice. If the same measurement feeds two parts of a calculation, the package handles that correctly. If two different instruments share a common calibration error, the package will treat them as independent and understate the combined uncertainty, and the only way to fix that today is to model the shared term explicitly.

Installing it, and the two constructors

Installation goes through Julia's built-in package manager. The latest version is available for Julia v1.0 and later, and in a Julia session you enter package manager mode with ] and run:

pkg> update
pkg> add Measurements

Older versions of the package are also available for Julia 0.4 to 0.7, which is a long compatibility tail for a package now on 2.x.

Then you load it and use it:

using Measurements

The module defines a new Measurement data type, and the objects can be created with two constructors:

measurement(value, uncertainty)
value ± uncertainty

Where value is the nominal value of the measurement and uncertainty is its uncertainty, assumed to be a standard deviation. That last qualifier is important and worth noting, because the word uncertainty is used loosely in the wild. Here it is specifically the standard deviation, not a half-width of a confidence interval, and the package will treat it as such when combining quantities.

The ± form is the same thing with a nicer syntax, and the presence of both constructors is deliberate rather than redundant. The function form is what you reach for when the value or the uncertainty is computed, and the infix form is what you write when both are literals. Making the uncertainty a first-class constructor argument rather than something you attach afterwards is the API decision that makes the whole package work: the uncertainty is part of the value, not metadata about it.

The documentation is at juliaphysics.github.io/Measurements.jl/stable/, and the README points at the Usage and Examples sections, and also mentions a technical appendix explaining how the package internally works for people integrating it into their own workflow.

The taster session, and what the results show

The README includes a REPL session, and it is worth reading closely because the numbers demonstrate the correlation handling rather than just the arithmetic.

julia> using Measurements

julia> a = measurement(4.5, 0.1)
4.5 ± 0.1

julia> b = 3.8 ± 0.4
3.8 ± 0.4

julia> 2a + b
12.8 ± 0.4472135954999579

julia> x = 8.4 ± 0.7

julia> x - x
0.0 ± 0.0

julia> x/x
1.0 ± 0.0

julia> x*x*x - x^3
0.0 ± 0.0

julia> sin(x)/cos(x) - tan(x)
-2.220446049250313e-16 ± 0.0 # They are equal within numerical accuracy

The first two lines are construction. a is measurement(4.5, 0.1) and prints as 4.5 ± 0.1, and b is 3.8 ± 0.4 written in the infix form and prints the same way.

Then 2a + b gives 12.8 ± 0.4472135954999579. Check that by hand: 2a has uncertainty 0.2, and combining 0.2 and 0.4 in quadrature gives the square root of 0.04 plus 0.16, which is the square root of 0.2, which is 0.4472135955. So the arithmetic is right, and the uncertainty is being combined correctly for independent quantities.

The rest of the session is the correlation story, and it is the interesting part. x - x is 0.0 ± 0.0. x/x is 1.0 ± 0.0. x*x*x - x^3 is 0.0 ± 0.0. And sin(x)/cos(x) - tan(x) is -2.220446049250313e-16 ± 0.0, with the comment that they are equal within numerical accuracy.

Read those four lines as a claim about semantics rather than about arithmetic. Any implementation that tracked only a scalar uncertainty per quantity would report a non-zero error for x - x, because it would add the uncertainty of x to the uncertainty of x. Getting 0.0 ± 0.0 there means the package is carrying derivative information through the expression tree and applying the chain rule, so that the derivatives of x with respect to x cancel.

The last line is the one that shows the limit of floating point rather than the package, and the comment on it says exactly that. The residual is the machine epsilon, and the uncertainty attached to it is zero, which is the point: the package is confident that sin(x)/cos(x) and tan(x) are the same quantity, and the tiny numeric difference is not uncertainty.

The session is short enough to type out yourself after installing, and it is the fastest way to confirm the package behaves the way the documentation claims.

How to evaluate it, and what to check first

There are five things to consider.

First, whether you are doing physics or something else. The package is built for physical measurements with standard-deviation uncertainties, and the linear error propagation theory is the model. If your errors are not standard deviations, or if your quantities are correlated for reasons the algebra does not reveal, you are outside what it can do.

Second, the correlation matrix limitation, and this is the one to check first because it is the one that can make a result wrong rather than merely limited. The package handles correlation that arises from the calculation. It does not let you declare that two separately measured quantities share a common error. If your uncertainty budget has a systematic component shared across instruments, you need to model that term yourself and combine it afterwards, and a package that reports a smaller total uncertainty than the truth is worse than no package at all.

Third, arbitrary precision, and why it is here. The package supports multiple precision numbers with uncertainties, which the README says is useful for measurements with very low relative error. That matters more than it sounds, because standard double precision cannot represent a value and a very small uncertainty on it independently, and a package that quietly loses the uncertainty at the bottom of the dynamic range would be a problem for anyone measuring something precisely.

Fourth, the extension points. The README lists what works with external packages: QuadGK.jl for numerical integration, numerical and automatic differentiation, physical units from external packages, and integration with Plots.jl. The @uncertain macro propagates uncertainty through any function of real arguments, including functions based on C or Fortran calls, which is what makes the package usable with code you did not write.

Fifth, the maintenance picture. The recent releases are v2.14.1 from 2025-10-18, v2.14.0 and v2.13.0 from June 2025, and the last push was on 2026-09-22. The project is not archived and the work continues. The badges show a build status, code coverage from Codecov, an Aqua QA quality check and a Fuzzy Tests badge, which is an unusual set for a scientific package and suggests the maintainers care about the numerical edge cases being tested rather than only the happy path.

What you get is a small, well-designed package with a clear theoretical basis, a published method, an explicit limitation, and a REPL session that demonstrates the point in six lines. The citation request is in the README twice, and for a package whose correctness is subtle, citing the method paper is a reasonable thing to ask.

Editorial conclusion

Adopt Measurements.jl if you are doing physics or measurement science in Julia and want uncertainties propagated correctly rather than approximately, because the functional correlation handling means cancellations in your algebra cancel in your error bars too. Do not adopt it if your uncertainty budget has a shared systematic component, since the package cannot express a correlation matrix and will understate the total uncertainty unless you model that term yourself. Before you commit, install it and type the six-line session from the README to confirm the behaviour on your own version, check that arbitrary precision is available in your workflow if you are measuring something with a very small relative error, and read the technical appendix in the documentation, since the package is small enough that understanding how it carries derivatives will tell you where its edges are.

Frequently asked questions

Official sources

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