Skip to content

Blog

Introducing Photometric Conditions

A "1000 lm" LED lamp and a "1000 lm" low-pressure sodium lamp do not look equally bright at night. The number on both boxes is a photopic value: it weights the lamp's spectrum with \(V(\lambda)\), the spectral sensitivity of the eye's cone cells, which drive vision in daylight. At night, rod cells take over, the sensitivity curve shifts towards blue (\(V'(\lambda)\)), and the same two lamps deliver roughly 2000 and 250 scotopic lumens respectively. Both figures are luminous fluxes. Both are expressed in lumens. And a program that adds or compares them computes a result that is wrong by up to a factor of eight:

auto led = 1000. * lm;     // photopic value from the datasheet
auto sodium = 250. * lm;   // scotopic value from a night-visibility model
auto total = led + sodium; // compiles everywhere, means nothing

To the best of our knowledge, no units library catches this today, because every one of them (including mp-units until now) models a lumen as a lumen. This post introduces photometric conditions: a way to keep photopic, scotopic, mesopic, and custom quantities in separate quantity hierarchies, so that the mistake above breaks at compile time, while everything the physics does allow keeps working.

Measurement uncertainty and measured constants

When you write constexpr double G = 6.674e-11; in your code, the type system makes a claim that is not true. It claims the value is exact. It is not. The Newtonian constant of gravitation is one of the least precisely known constants in physics. CODATA 2018 lists it as 6.674 30(15) × 10⁻¹¹ m³ kg⁻¹ s⁻², and the (15) means the fifth significant digit is already uncertain. Only four digits of G are actually known. Every result derived from that double inherits an uncertainty that the program neither tracks nor reports. The code happily prints ten significant digits of a solar mass computed from a constant that guarantees four.

mp-units now models this honestly. This post introduces the uncertain<T> representation type, the standard_uncertainty and relative_standard_uncertainty metadata for measured constants, and the measurement_of helper that connects them.

Introducing Logarithmic Quantities and Units

Decibels are everywhere in engineering. Signal levels in dBm, sound pressure in dB SPL, voltage gain in dB, filter slopes in dB/octave. The neper, pH, and stellar magnitude share the same structure. Yet, to the best of our knowledge, no general-purpose units library models logarithmic quantities correctly. Most do not model them at all. The few that do treat a decibel as a non-linear scale or an offset unit, and that choice gets the arithmetic wrong in ways that compile silently.

This article is a request for feedback. We believe we have a correct design, derived from the same affine-space model we introduced for absolute quantities. It also aims to stay consistent with the ISO/IEC 80000 standards: especially IEC 80000-15:2026, Logarithmic quantities and their units, which consolidates the logarithmic-quantity rules once held in ISO 80000-1:2009 (Annex C); together with ISO 80000-2 (the logarithm functions lb, ln, lg), ISO 80000-8 (acoustics), and IEC 80000-13 (information theory). We have read those against this design, cite them throughout, and call out the one place we knowingly diverge from them (Open Question 5).

This post describes the design in full, from the quantity spec to the named units, the arithmetic, the conversions, and every domain we surveyed (audio, RF, acoustics, chemistry, astronomy, music, information theory). Then it lays out the open questions, each with every alternative we considered and our current preference. Before we implement any of this in mp-units, we want the people who use these quantities daily to tell us where we are wrong.

Bringing Safety to HEP

High-Energy Physics software is routinely trusted with complex detector geometries spanning millions of volumes, critical tracking and reconstruction algorithms, and multi-day simulations running on the Grid. A single silent unit mismatch in a double can invalidate an entire analysis or produce detector geometry that is 10× the wrong size. This post shows how mp-units can bring compile-time safety to HEP codebases (including a dedicated HEP system of quantities and units) and how large projects like ATLAS can adopt it incrementally without requiring a big-bang rewrite.

Why a Quantity Has a Character

A few years ago at CppCon, an engineer who works with electrical power systems every day stopped me after a talk. He told me that his team confuses active power, reactive power, apparent power, and complex power all the time, and that the mistake is easy to make and expensive to find. Then he said the sentence that has stuck with me since: a units library that will not make those four incompatible types is of no use in his industry.

He is right. And he is not alone.

Note: Revised on July 5, 2026 to incorporate the feedback in the comments below.

  • in Feature
  • 7 min read

Units Meet Linear Algebra: Two Approaches, Two Problems

How do units and linear algebra fit together? We get that question often. The honest answer is that two different questions hide inside it, and they have different solutions. The occasion for answering now is concrete: mp-units ships opt-in integrations that let mainstream linear algebra libraries (Eigen, GLM, and Blaze) act directly as the representation type of a quantity.

Report from the Brno 2026 ISO C++ Committee meeting

The Brno 2026 ISO C++ Committee meeting has just finished. It was the first meeting of the C++29 cycle, and a surprising amount already landed in the working draft. Below I share the highlights voted in during the closing plenary, followed by an update on the quantities and units standardization effort.

Preventing Integer Overflow in Physical Computations

Integers overflow. That is not a controversial statement. What is surprising is how easily overflow can hide behind the abstraction of a units library.

Most developers immediately think of explicit or implicit scaling operations — calling .in(unit) to convert a quantity, constructing a quantity from a different unit, or assigning between quantities with different units. These are indeed places where overflow can occur, and the library cannot prevent it at compile time when the values are only known at runtime. But at least these operations are visible in your code: you wrote the conversion, you asked for the scaling, and you can reason about whether the multiplication or division might overflow your integer type.

The far more insidious problem is what happens when you don't ask for a conversion.

When you write 1 * m + 1 * ft, the library must automatically convert both operands to a common unit before performing the addition. That conversion — which you never explicitly requested — involves multiplication or division by scaling factors. With integer representations, those scaling operations can overflow silently, producing garbage results that propagate through your calculations undetected.

No compile-time programming can prevent this. The values are only known at runtime. But very few libraries provide proper tools to detect it.

This article explains why that limitation is real, how other libraries have tried to work around it, and what mp-units provides to close the gap as tightly as the language allows.

Range-Validated Quantity Points

Physical units libraries have always been very good at preventing dimensional errors and unit mismatches. But there is a category of correctness that they have universally ignored: domain constraints on quantity point values.

A latitude is not just a length divided by a radius. It is a value that lives in \([-90°, +90°]\); anything outside that range is physically meaningless. An angle used in bearing navigation wraps cyclically around a circle; treating it as an unbounded real number ignores a fundamental property of the domain. A clinical body-temperature sensor should reject a reading of \(44\ \mathrm{°C}\) at the API boundary, not silently pass it downstream.

Type-level constraint enforcement for quantity points with this level of flexibility is a relatively unexplored area in mainstream physical units libraries. The approach we present here is novel and experimental — we are certain there are edge cases and design considerations we haven't yet discovered.

This article describes the motivation in depth, the design we arrived at, and the open questions we would love the community's help to answer.

Report from the Croydon 2026 ISO C++ Committee meeting

It has been 1.5 years since the last major update on the ISO C++ standardization progress here. It is not that I got lazy 😉, but there was really not much to share.

This time, things were different. We achieved a nearly unprecedented success — one probably not even expected by most, definitely not by me! 🎉

Keep reading to learn more...