mp-units/latest/blog/2025/06/16/introducing-absolute-quantities/

[giscus[bot]]

mp-units/latest/blog/2025/06/16/introducing-absolute-quantities/

The quantities and units library for C++

https://mpusz.github.io/mp-units/latest/blog/2025/06/16/introducing-absolute-quantities/

[Spammed]

First of all, I greatly appreciate the work that has been done here and I am quite sure that the C++ world will benefit greatly from it.

A core idea of V3 is ‘[...] absolute quantities share properties of both deltas and points [...]’.
I believe in this, but I still feel some inner resistance. I hope to gain practical experience with it at some point.

Probably a minor detail:
"Adding an absolute quantity to a point yields a point shifted by the given amount, and adding a delta to a point yields another point."
I don't see any difference between ‘yields a point shifted’ and ‘yields another point’.
Are two different things being described here, or is it the same thing twice, just in different words?

[mpusz]

Hi @Spammed,

Thanks a lot for your feedback!

I believe this is the right approach, but I also have some reservations. This is why I wrote this article, and I am seeking feedback before I roll out V3 to all my users. I would love to hear what people think. If that seems like the right approach, we will take it. If it is broken, I would love to hear the rationale before I spend too much time on it and provide it as V3.

This quote may indeed be unfortunate. As absolute quantity is not a point but an absolute amount of a thing, I wanted to make it obvious. I also used AI in the process of reviewing and improving the article, and this might be a side effect of this as well. Anyway, you are right. Both try to describe the same thing. As the table directly below it confirms. Should I reword it?

[Spammed]

I'll just try to put my thoughts on this into words. I'm not sure whether the “arguments” haven't already been discussed at length.

I) The term “vector” is not clearly defined on its own. When I hear the term 'vector', I think of a tuple of numbers that only makes sense in conjunction with a reference-frame and defined 'metric'. In addition, there are position vectors and direction vectors, each with their own arithmetic. In short: I would avoid using the term “vector” as a synonym for “difference” or “delta”.

II) It seems to me that “absolute” serves two purposes:
a) It represents a physical reality (as with mass and energy) that some quantities only occur in positive amounts.
b) Simplified handling (as with length or time).

I think length and time are essentially distances. This can be seen from the fact that places and points in time only make sense in conjunction with a reference point. Such a reference point is pure convention.
In this respect, I perceive the signs of lengths or times as a natural expression for “in front of/before” or “behind/after” as seen from the reference point.

How about separating purposes a) and b)? The term “absolute” would then stand for “non-negative quantity with an implicit/natural reference point '0'”,
while the term “relative” would stand for “signed quantity without a natural reference point” or “ quantity with an explicit reference point”.

In this spirit:

// 'Mass' may definded as a dimension with 'absolute'-semantik. quantity m1 = 20 * kg; // absolute quantity (measured from true zero) quantity m2 = 5 * kg; // absolute quantity (measured from true zero) quantity m2 = m1 - m2; // OK, = 15 * kg, absolute quantity (measured from true zero) //quantity m3 = m2 - m1; // ERROR quantity dm2 = (m2 - m1).delta(); // delta quantity (difference) quantity mp = point<kg>(20); // point quantity (relative to the natural origin = true zero) quantity normal_weight = point<kg>(20); // point quantity (relative to the natural origin = true zero) quantity mp = point<kg, normal_weight>(2); // point quantity (relative to the normal_weight)

but

// 'Length' may defined as a dimension with 'relative'-semantik. quantity l1 = 10 * m; // delta quantity (difference) quantity l2 = 20 * m; // delta quantity (difference) quantity dl1 = delta<m>(20); // delta quantity (difference) quantity dl2 = l2-l1; // delta quantity (difference) quantity pos1 = point<m>(20); // point quantity (relative to the default 'explicit' origin 'global_origin') quantity pos2 = point<m, pos1>(2); // point quantity (relative to pos1) quantity dl3 = pos2 - pos1 // delta quantity (difference), feasible, because a common reference-point could be determined.

[mpusz]

Thanks again for the feedback! I just submited an updated version of the article that:

• fixes the addition description issue that you pointed out before
• removed "vector" word from the table (I agree with your rationale)

You are right about II a). Regarding length and time, it depends 😉 Even ISQ specifies some lengths as non-negative (width, thickness, diameter, radius). Also, as long as we can imagine negative altitudes (those really should be modelled as points), it is hard to imagine a person with a negative height. Of course, I can compare the height of two persons and end up with a negative value, but the latter one is definitely a delta. If we say that length and time are always relative, then we cannot model any lengths or durations as non-negative. I believe that we can't physically measure a negative length with a ruler or any other tool 😉. If we talk about negative length, we either talk about:

• a 1D vector/displacement (e.g., as an input to a function calculating the the velocity for a car driving in reverse gear),
• a delta of two absolute lengths (see the heights example above),
• or a point relative to some reference (e.g., altitude).

Regarding your example, how would you like to make m2 - m1 a compile-time error? The value is known only at runtime, so we can't fail at compile-time. Or do you mean an erroneous calculation, but possible to compile (in such a case, it should not be commented out).

We also can't use normal_weight or pos1 in a template parameter, as it is not a compile-time value. We need to specify a custom origin. With this, we can represent tared or relative masses or lengths. More on this can be found here: https://mpusz.github.io/mp-units/latest/users_guide/framework_basics/the_affine_space/#relative-point-origin.

[Spammed]

Uh, oh, I've taken another wrong turn and completely ignored “compile-time”. Sorry about that part.

Grumble :-) :
But it's not true that only positive distances can be marked on a ruler or scale.
And a person's height is a distance (from the soles of their feet to the top of their head).
Worse still, the definition of 'height' includes a direction (metric).

You see, my thoughts keep coming back to coordinate systems (= origin + orientation + metric) and operations defined “within” them. But this do not leading to an argument.

So I'm left with my gut feeling:
I still believe, with a certain uneasiness, that the basic idea of “V3” is a real improvement.

[mpusz]

Thanks!

But it's not true that only positive distances can be marked on a ruler or scale.
And a person's height is a distance (from the soles of their feet to the top of their head).

LOL 🤣 Yeah, I can imagine it. Next time I will need to fill a medical form, when they ask me about my height, I will provide a negative value and a small comment saying that this time I was measuring from the tip of my head downwards 😂

You know me, I am a big proponent of affine space, and I also reason in terms of coordinate systems. However, the production experience from many projects and companies shows clearly that most people do not use affine space abstractions (even though they often should). Additionally, the absolute temperature as a point works and is safe, but it is also cumbersome to use. This is why I am proposing this third new abstraction. I am glad that you see those as an improvement.

[benmesander]

I wrote a time-specific C++ metrology library many years ago, with the same concepts of deltas and absolute values. I came across a couple of interesting points which may interest you.

One thing that comes up with time specific points are leap seconds. These cause discontinuities in the time scale. In particular, deltas across these points require consulting a leap second table to see if the delta spans one or more discontinuities, and the length must be adjusted if so. Additionally, for a general solution, in the past, the frequency of time was adjusted to avoid leap seconds, and this frequency change causes the delta calculation to differ. Finally, the time library should know if it is near a leap second opportunity, and if so, it needs to fetch the current leap second table from some source, such as GNSS. Additionally, if a delta calculation into the future spans a potential leap second opportunity, a similar fetch must be done, although if it's far enough in the future, then the computation has to be marked as approximate, rather than exact.

[mpusz]

Hi @benmesander, thanks for sharing your experience. This library is not meant to replace std::chrono. Conversely, they are meant to work together and complement each other. std::chrono will still be useful for clocks, calendars, leap seconds, and other similar applications. This library will be responsible for physical equations involving time. The time-related types from both libraries are interconvertible, making it easy to apply them to any scenario.

Please check the following for more details:

• Interoperability with the C++ Standard Library
• Tutorial 6: Interop with std::chrono