Dimensionless Quantities

The quantities discussed so far always had specific types and physical dimensions. However, this isn't always the case. Some computations produce "dimensionless" quantities. ISO defines them as quantities of dimension one:

ISO/IEC Guide 99

• Quantity for which all the exponents of the factors corresponding to the base quantities in its quantity dimension are zero.
• The measurement units and values of quantities of dimension one are numbers, but such quantities convey more information than a number.
• Some quantities of dimension one are defined as the ratios of two quantities of the same kind.
• Numbers of entities are quantities of dimension one.

Dividing two quantities of the same kind

Dividing two quantities of the same kind always results in a quantity of dimension one. However, depending on what type of quantities we divide or what their units are, we may end up with slightly different results.

Note

In mp-units, dividing two quantities of the same dimension always results in a quantity with the dimension being dimension_one. This is often different for other physical units libraries, which may return a raw representation type for such cases. A raw value is also always returned from the division of two std::chrono::duration objects.

To read more about the reasoning for this design decision, please check our FAQ.

Dividing quantities of the same type

First, let's analyze what happens if we divide two quantities of the same type:

constexpr QuantityOf<dimensionless> auto q = isq::height(200 * m) / isq::height(50 * m);

In such a case, we end up with a dimensionless quantity that has the following properties:

static_assert(q.quantity_spec == dimensionless);
static_assert(q.dimension == dimension_one);
static_assert(q.unit == one);

In case we would like to print its value, we would see a raw value of 4 in the output with no unit being printed.

Dividing quantities of different types

Now let's see what happens if we divide quantities of the same dimension and unit but which have different quantity types:

constexpr QuantityOf<dimensionless> auto q = isq::work(200 * J) / isq::heat(50 * J);

Again we end up with dimension_one and one, but this time:

static_assert(q.quantity_spec == isq::work / isq::heat);

As shown above, the result is not of a dimensionless type anymore. Instead, we get a quantity type derived from the performed quantity equation. According to the ISQ, work divided by heat is the recipe for the thermodynamic efficiency quantity, thus:

static_assert(implicitly_convertible(q.quantity_spec, isq::efficiency_thermodynamics));

Note

The quantity of isq::efficiency_thermodynamics is of a kind dimensionless, so it is implicitly convertible to dimensionless and satisfies the QuantityOf<dimensionless> concept.

Dividing quantities of different units

Now, let's see what happens when we divide two quantities of the same type but different units:

constexpr QuantityOf<dimensionless> auto q = isq::height(4 * km) / isq::height(2 * m);

This time, we still get a quantity of the dimensionless type with a dimension_one as its dimension. However, the resulting unit is not one anymore:

static_assert(q.unit == mag_power<10, 3> * one);

In case we would print the text output of this quantity, we would not see a raw value of 2000, but 2 km/m.

First, it may look surprising, but this is consistent with dividing quantities of different dimensions. For example, if we divide 4 * km / 2 * s, we do not expect km to be "expanded" to m before the division, right? We would expect the result of 2 km/s, which is exactly what we get when we divide quantities of the same kind.

This is a compelling feature that allows us to express huge or tiny ratios without the need for big and expensive representation types. With this, we can easily define things like a Hubble's constant that uses a unit that is proportional to the ratio of kilometers per megaparsecs, which are both units of length:

inline constexpr struct hubble_constant final :
    named_unit<{u8"H₀", "H_0"}, mag_ratio<701, 10> * si::kilo<si::metre> / si::second / si::mega<parsec>> {} hubble_constant;

Counts of things

Another important use case for dimensionless quantities is to provide strong types for counts of things. For example:

• ISO-80000-3 provides a rotation quantity defined as the number of revolutions,
• IEC-80000-6 provides a number of turns in a winding quantity,
• IEC-80000-13 provides a Hamming distance quantity defined as the number of digit positions in which the corresponding digits of two words of the same length are different.

Thanks to assigning strong names to such quantities, later on, they can be explicitly used as arguments in the quantity equations of other quantities deriving from them.

Predefined units of the dimensionless quantity

As we observed above, the most common unit for dimensionless quantities is one. It has the ratio of 1 and does not output any textual symbol.

Important: one is an identity

A unit one is special in the entire type system of units as it is considered to be an identity operand in the unit symbolic expressions. This means that, for example:

static_assert(one * one == one);
static_assert(one * si::metre == si::metre);
static_assert(si::metre / si::metre == one);

The same is also true for dimension_one and dimensionless in the domains of dimensions and quantity specifications.

Besides the unit one, there are a few other scaled units predefined in the library for usage with dimensionless quantities:

inline constexpr struct percent final : named_unit<"%", mag_ratio<1, 100> * one> {} percent;
inline constexpr struct per_mille final : named_unit<{u8"‰", "%o"}, mag_ratio<1, 1000> * one> {} per_mille;
inline constexpr struct parts_per_million final : named_unit<"ppm", mag_ratio<1, 1'000'000> * one> {} parts_per_million;
inline constexpr auto ppm = parts_per_million;

Info

Units defined in terms of one will be addable, subtractible, comparable, and convertible with one. If that is not your intent, you should instead base your units on kind_of<dimensionless>. This will make each such unit "independent" from other units.

Superpowers of the unit one

Quantities implicitly convertible to dimensionless with the unit equivalent to one are the only ones that are:

• implicitly constructible from the raw value,
• explicitly convertible to a raw value,
• comparable to a raw value.

quantity<one> inc(quantity<one> q) { return q + 1; }
void legacy(double) { /* ... */ }

if (auto q = inc(42); q != 0)
  legacy(static_cast<int>(q));

This property also expands to usual arithmetic operators.

Note

Those rules do not apply to all the dimensionless quantities. It would be unsafe and misleading to allow such operations on units with a magnitude different than 1 (e.g., percent) or for quantities that are not implicitly convertible to dimensionless (e.g., angular_measure).

Angular quantities

Special, often controversial, examples of dimensionless quantities are an angular measure and solid angular measure quantities that are defined in the ISQ to be the result of a division of \(arc\; length / radius\) and \(area / radius^2\) respectively. Moreover, ISQ also explicitly states that both can be expressed in the unit one. This means that both angular measure and solid angular measure should be of a kind dimensionless.

On the other hand, ISQ also specifies that a unit radian can be used for angular measure, and a unit steradian can be used for solid angular measure. Those should not be mixed or used to express other types of dimensionless quantities. This means that both angular measure and solid angular measure should also be quantity kinds by themselves.

Note

Many people claim that angle being a dimensionless quantity is a bad idea. There are proposals submitted to make an angle a base quantity and rad to become a base unit. More on this topic can be found in the "Strong Angular System" chapter.

Radians and degrees support

Thanks to the usage of magnitudes the library provides efficient strong types for all angular types. This means that with the built-in support for magnitudes of \(\pi\) we can provide accurate conversions between radians and degrees. The library also provides common trigonometric functions for angular quantities:

using namespace mp_units::si::unit_symbols;
using mp_units::angular::unit_symbols::rad;
using mp_units::angular::unit_symbols::deg;
using mp_units::angular::unit_symbols::grad;

quantity speed = 110 * km / h;
quantity rate_of_climb = -0.63657 * m / s;
quantity glide_ratio = speed / -rate_of_climb;
quantity glide_angle = angular::asin(1 / glide_ratio);

std::println("Glide ratio: {::N[.1f]}", glide_ratio.in(one));
std::println("Glide angle:");
std::println(" - {::N[.4f]}", glide_angle.in(rad));
std::println(" - {::N[.2f]}", glide_angle.in(deg));
std::println(" - {::N[.2f]}", glide_angle.in(grad));

The above program prints:

Glide ratio: 48.0
Glide angle:
 - 0.0208 rad
 - 1.19°
 - 1.33ᵍ

Note

In the production code the above speed and rate_of_climb quantities should probably be modelled as separate typed quantities of the same kind.

Nested quantity kinds

Angular quantities are not the only ones with such a "strange" behavior. Another but a similar case is a storage capacity quantity specified in IEC-80000-13 that again allows expressing it in both one and bit units.

Those cases make dimensionless quantities an exceptional tree in the library. This quantity hierarchy contains more than one quantity kind and more than one unit in its tree:

flowchart TD
    dimensionless["<b>dimensionless</b><br>[one]"]
    dimensionless --- rotation["<b>rotation</b>"]
    dimensionless --- thermodynamic_efficiency["<b>thermodynamic_efficiency</b><br><i>(work / heat)</i>"]
    dimensionless --- angular_measure["<b>angular_measure</b>🔒<br><i>(arc_length / radius)</i><br>[rad]"]
    angular_measure --- rotational_displacement["<b>rotational_displacement</b><br><i>(path_length / radius)</i>"]
    angular_measure --- phase_angle["<b>phase_angle</b>"]
    dimensionless --- solid_angular_measure["<b>solid_angular_measure</b>🔒<br><i>(area / radius<sup>2</sup>)</i><br>[sr]"]
    dimensionless --- drag_factor["<b>drag_factor</b><br><i>(drag_force / (mass_density * speed<sup>2</sup> * area))</i>"]
    dimensionless --- storage_capacity["<b>storage_capacity</b>🔒<br>[bit]"] --- equivalent_binary_storage_capacity["<b>equivalent_binary_storage_capacity</b>"]
    dimensionless --- ...

To provide such support in the library, we use the is_kind specifier in the quantity specification. This feature is not limited to dimensionless quantities—it can be used with any dimension to create distinct quantity kinds. For a comprehensive explanation of is_kind and how to use it with dimensional quantities, see Creating distinct quantity kinds with is_kind.

For dimensionless quantities specifically, the is_kind specifier is applied as follows:

C++23C++20Portable

inline constexpr struct angular_measure final : quantity_spec<dimensionless, arc_length / radius, is_kind> {} angular_measure;
inline constexpr struct solid_angular_measure final : quantity_spec<dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;
inline constexpr struct storage_capacity final : quantity_spec<dimensionless, is_kind> {} storage_capacity;

inline constexpr struct angular_measure final : quantity_spec<angular_measure, dimensionless, arc_length / radius, is_kind> {} angular_measure;
inline constexpr struct solid_angular_measure final : quantity_spec<solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;
inline constexpr struct storage_capacity final : quantity_spec<storage_capacity, dimensionless, is_kind> {} storage_capacity;

QUANTITY_SPEC(angular_measure, dimensionless, arc_length / radius, is_kind);
QUANTITY_SPEC(solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind);
QUANTITY_SPEC(storage_capacity, dimensionless, is_kind);

With the above, we can constrain radian, steradian, and bit to be allowed for usage with specific quantity kinds only:

inline constexpr struct radian final : named_unit<"rad", metre / metre, kind_of<isq::angular_measure>> {} radian;
inline constexpr struct steradian final : named_unit<"sr", square(metre) / square(metre), kind_of<isq::solid_angular_measure>> {} steradian;
inline constexpr struct bit final : named_unit<"bit", one, kind_of<storage_capacity>> {} bit;

but still allow the usage of one and its scaled versions for such quantities.

Info

It is worth mentioning here that converting up the hierarchy beyond a subkind requires an explicit conversion. For example:

static_assert(implicitly_convertible(isq::rotation, dimensionless));
static_assert(!implicitly_convertible(isq::angular_measure, dimensionless));
static_assert(explicitly_convertible(isq::angular_measure, dimensionless));

This increases type safety and prevents accidental quantities with invalid units. For example, a result of a conversion from isq::angular_measure[rad] to dimensionless would be a reference of dimensionless[rad], which contains an incorrect unit for a dimensionless quantity. Such a conversion must be explicit and be preceded by an explicit unit conversion:

quantity q1 = isq::angular_measure(42. * rad);
quantity<dimensionless[one]> q2 = dimensionless(q1.in(one));

Using dimensionless quantities as strongly-typed numeric types

For decades, the C++ community has sought ways to create strongly-typed wrappers for fundamental types to prevent bugs that arise from accidentally mixing semantically different values. Consider functions like process(10, 20) or draw_point(x, y)—when parameters have the same underlying type (int, double), it's easy to swap them accidentally, leading to subtle bugs that compilers cannot detect.

The C++ standard library provides no built-in support for creating such strong types. However, several third-party libraries like NamedType, type_safe, and PSsst have emerged to fill this gap, providing generic solutions for creating distinct types from primitives. These approaches typically require manual definition of operators for each type or explicit opt-in for each operation, and they don't inherently understand derived quantities or dimensional analysis.

mp-units offers a unique approach: leverage dimensionless quantities to create strongly-typed numeric types that benefit from the library's built-in dimensional analysis infrastructure. This isn't about physical dimensions or scaling by units factors—it's about using the framework's type system to prevent mixing semantically different counts, coordinates, or identifiers while maintaining zero-overhead and natural arithmetic semantics.

Type safety vs convenience trade-offs

Implicit construction: The convenience-first approach

The Superpowers of the unit one described before provide a convenient way to work with dimensionless quantities. Quantities implicitly convertible to dimensionless with unit one can be implicitly constructed from raw values, explicitly converted back to raw values, and compared with raw values. This makes them easy to use with existing code and APIs.

This convenience comes at a cost: such syntax behaves a bit like raw int or double values when it comes to type safety.

Consider the following example:

inline constexpr struct item_count final : quantity_spec<dimensionless> {} item_count;
inline constexpr struct widget_count final : quantity_spec<dimensionless> {} widget_count;

void process(quantity<item_count[one]> items, quantity<widget_count[one]> widgets)
{
  /* ... */
}

process(10, 20);                       // Which is items? Which is widgets? Unclear!
process(10 * one, 20 * one);           // Which is items? Which is widgets? Unclear!

// With explicit types, the compiler checks the order
quantity items = item_count(10);
quantity widgets = widget_count(20);
process(items, widgets);    // OK
// process(widgets, items); // Compile-time error!

When you already have typed quantities, the compiler does enforce the correct order—swapping them produces a compile error. However, the real problem is calling the function with raw values like process(10, 20) where there's no indication which parameter is which. This is better than raw int or double (at least functions can document their types), but it's still unclear at the call site when using literal values.

Another drawback of such a hierarchy is that these types model dimensionless tagged numbers which means they can be mixed in arithmetic operations and comparisons:

quantity items = item_count(10);
quantity widgets = widget_count(20);

// These compile but may be semantically incorrect:
quantity total = items + widgets;    // Compiles! Both convert to dimensionless
if (items < widgets) {               // Compiles! Comparison through dimensionless
  // ...
}

While the compiler allows these operations, they may not make semantic sense—adding items and widgets together, or comparing them directly, is likely a logic error in most domains.

Explicit construction with is_kind: Maximum type safety

To address the type safety concerns shown above, mp-units offers the is_kind specifier. When you mark a quantity with is_kind, it becomes a distinct quantity kind that cannot be implicitly mixed with other kinds (even with the parent kind). Such sub-kinds inherit properties of the parent kind (dimension, character, unit, etc.). This also disables the implicit conversion from raw values because those are now more than just tagged numbers. They have strong semantical meaning and the library should respect that.

This however, creates an important trade-off:

Without is_kind (implicit conversion)With is_kind (explicit construction)

inline constexpr struct item_count final : quantity_spec<dimensionless> {} item_count;
inline constexpr struct widget_count final : quantity_spec<dimensionless> {} widget_count;

void process(quantity<item_count[one]> items, quantity<widget_count[one]> widgets)
{
  /* ... */
}

// Can call with raw values - convenient but unclear
process(10, 20);             // ⚠️ Which parameter is which? No way to tell!

// With typed quantities, the compiler does enforce order
quantity items = item_count(10);
quantity widgets = widget_count(20);
process(items, widgets);     // ✅ OK - correct order
process(widgets, items);     // ❌ Compile error! Good.

// Another problem: can mix semantically different types in arithmetic
auto total = items + widgets;  // ⚠️ Compiles! Both convert to dimensionless
if (items < widgets) {         // ⚠️ Compiles! Comparison through dimensionless
  // ...
}

Pros: Convenient—works with raw values, typed quantities enforce correct parameter order

void draw_rect(quantity<pixel_x[one]> x, quantity<pixel_y[one]> y,
               quantity<pixel_x[one]> width, quantity<pixel_y[one]> height)
{
  // ...
}

// All arguments may be passed as raw numbers (when we are sure what we are doing)
draw_rect(10, 20, 100, 50);

Cons: Using raw values at call sites lacks clarity; can mix different dimensionless types in arithmetic and comparisons because they share common dimensionless root

inline constexpr struct item_count final : quantity_spec<dimensionless, is_kind> {} item_count;
inline constexpr struct widget_count final : quantity_spec<dimensionless, is_kind> {} widget_count;

void process(quantity<item_count[one]> items, quantity<widget_count[one]> widgets)
{
  /* ... */
}

// Cannot call with raw values - must be explicit
process(10, 20);             // ❌ Compile error! Good.

// Must use typed quantities, and order is enforced
quantity items = item_count(10);
quantity widgets = widget_count(20);
process(items, widgets);     // ✅ OK - correct order
process(widgets, items);     // ❌ Compile error! Good.

// Arithmetic operations also enforce type safety
auto mixed = items + widgets;  // ❌ Compile error! Good.
if (items < widgets) {         // ❌ Compile error! Good.
  // ...
}

Pros: Maximum type safety—distinct types cannot be accidentally mixed or reordered

Cons: Less convenient—requires explicit construction everywhere, especially verbose for functions with multiple parameters:

void draw_rect(quantity<pixel_x[one]> x, quantity<pixel_y[one]> y,
               quantity<pixel_x[one]> width, quantity<pixel_y[one]> height)
{
  // ...
}

// All parameters need explicit construction
draw_rect(quantity<pixel_x[one]>{10}, quantity<pixel_y[one]>{20},
          quantity<pixel_x[one]>{100}, quantity<pixel_y[one]>{50});
// or to use quantity_spec as a quantity creation helper
draw_rect(pixel_x(10), pixel_y(20), pixel_x(100), pixel_y(50));

Choosing the right approach:

• Use is_kind when type safety is paramount and you want to prevent any accidental mixing of semantically different counts or coordinates. Accept the verbosity of explicit construction.

• Skip is_kind for convenience when the types rarely interact and the risk of mixing them is low, or when you need to frequently pass raw values to functions.

Comparison with traditional strong-type approaches

Traditional approaches to creating strong numeric types each face different trade-offs:

Type aliases (unsafe)Wrapper classes (verbose)Generic libraries (NamedType, type_safe, PSsst)mp-units (specialized for numeric types)

using PixelX = int;
using PixelY = int;
using PixelArea = int;

void draw_point(PixelX x, PixelY y) { /* ... */ }

PixelArea calculate_area(PixelX width, PixelY height)
{
  return width * height;
}

PixelX x = 100;
PixelY y = 200;
draw_point(x, y);   // ✅ Good!
draw_point(y, x);   // ⚠️ Compiles! Wrong order.

// Can mix with unrelated types
int random = 42;
draw_point(random, random);  // ⚠️ Compiles!

PixelX width = 1920;
PixelY height = 1080;
PixelArea area = calculate_area(width, height);      // ✅ Good!
PixelArea bad_area = calculate_area(height, width);  // ⚠️ Compiles! Wrong order.

std::cout << "Area: " << area << " = " << area / 2073600.0 << " FHD = " << area / 8294400.0 << " 4K\n";

Problem: No type safety—all errors compile. Manual scaling requires magic numbers.

struct PixelX { int value; };
struct PixelY { int value; };
struct PixelArea { int value; };

void draw_point(PixelX x, PixelY y) { /* ... */ }

PixelArea calculate_area(PixelX width, PixelY height)
{
  return PixelArea{width.value * height.value};  // Manual unwrap & wrap
}

PixelX x{100};
PixelY y{200};
draw_point(x, y);   // ✅ Good!
draw_point(y, x);   // ❌ Compile error! Good.

PixelX width{1920};
PixelY height{1080};
PixelArea area = calculate_area(width, height);      // ✅ Good!
PixelArea bad_area = calculate_area(height, width);  // ❌ Compile error! Good.
// But: no help with derived quantities - must manually manage relationships
// Need PixelArea / PixelX = PixelY? Define more operators manually!

std::cout << "Area: " << area.value << " = " << area.value / 2073600.0 << " FHD = " << area.value / 8294400.0 << " 4K\n";

Problem: Type safety requires boilerplate. No dimensional analysis or derived quantities.

using PixelX = fluent::NamedType<int, struct PixelXTag, fluent::Addable>;
using PixelY = fluent::NamedType<int, struct PixelYTag, fluent::Addable>;
using PixelArea = fluent::NamedType<int, struct PixelAreaTag, fluent::Addable>;

void draw_point(PixelX x, PixelY y) { /* ... */ }

PixelArea calculate_area(PixelX width, PixelY height)
{
  return PixelArea{width.get() * height.get()};  // Manual unwrap & wrap
}

PixelX x{100};
PixelY y{200};
draw_point(x, y);   // ✅ Good!
draw_point(y, x);   // ❌ Compile error! Good.

PixelX width{1920};
PixelY height{1080};
PixelArea area = calculate_area(width, height);      // ✅ Good!
PixelArea bad_area = calculate_area(height, width);  // ❌ Compile error! Good.
// But: no automatic understanding that PixelX × PixelY → PixelArea

std::cout << "Area: " << area.get() << " = " << area.get() / 2073600.0 << " FHD = " << area.get() / 8294400.0 << " 4K\n";

Problem: Strong types but no dimensional analysis. Must manually extract, compute, and wrap.

Examples: NamedType, type_safe, PSsst

inline constexpr struct pixel_x final : quantity_spec<dimensionless, is_kind> {} pixel_x;
inline constexpr struct pixel_y final : quantity_spec<dimensionless, is_kind> {} pixel_y;
inline constexpr struct pixel_area final : quantity_spec<dimensionless, pixel_x * pixel_y, is_kind> {} pixel_area;

inline constexpr struct fhd final : named_unit<"FHD", mag<1920 * 1080> * one, kind_of<pixel_area>> {} fhd;
inline constexpr struct uhd_4k final : named_unit<"4K", mag<3840 * 2160> * one, kind_of<pixel_area>> {} uhd_4k;

void draw_point(quantity<pixel_x[one], int> x>, quantity<pixel_y[one], int> y>) { /* ... */ }

quantity<pixel_area[one], int> calculate_area(quantity<pixel_x[one], int> width,
                                              quantity<pixel_y[one], int> height)
{
  return width * height;
}

quantity x = pixel_x(100);
quantity y = pixel_y(200);
draw_point(x, y);   // ✅ Good!
draw_point(y, x);   // ❌ Compile error! Good.

quantity width = pixel_x(1920);
quantity height = pixel_y(1080);
quantity area = calculate_area(width, height);      // ✅ Good!
quantity bad_area = calculate_area(height, width);  // ❌ Compile error! Good.

std::cout << "Area: " << area << " = " << area.in<double>(fhd) << " = " << area.in<double>(uhd_4k) << '\n';

Advantages: Type safety + dimensional analysis + automatic derived quantities. Custom units with automatic conversions. Zero overhead, minimal boilerplate.

Key comparison:

Feature	Type Alias	Wrapper Class	Generic Library	mp-units dimensionless
Type safety	❌	✅	✅	✅
Zero overhead	✅	✅	✅	✅
Arithmetic operators	✅	Manual	Manual	✅
Derived quantities	❌	Manual	❌	✅
Dimensional analysis	❌	Manual	❌	✅
Unit conversions	❌	Manual	❌	✅
Boilerplate per type	Minimal	High	Medium	Minimal

mp-units specializes in numeric types, enabling automatic arithmetic and dimensional analysis that generic strong-type libraries cannot provide.

Why dimensionless instead of custom dimensions?

Dimensionless quantities with is_kind automatically work with unit one and its scaled versions, support explicit conversions to/from raw types, and participate in ISQ for derived quantities. Custom dimensions are better for physically distinct concepts (see Workshop: Custom Base Dimensions).

For a comprehensive example of using dimensionless quantities as strongly-typed numeric types, see Workshop: Strongly-Typed Counts.