mp-units V2 on ACCU 2023

[mpusz]

Hi,

I just provided a talk about V2 at the ACCU 2023 conference. You can find the slides here: https://github.com/train-it-eu/conf-slides/blob/master/2023.04%20-%20ACCU%202023/mp-units%20-%20Lessons%20learned%20and%20a%20new%20library%20design.pdf. In case you have any feedback, thoughts, or questions please do not hesitate to rise them here.

[chiphogg]

Thanks for sharing these slides!

Without speaker notes, I'm guessing at the point of a couple slides, but I'm familiar enough with the background context that I think I can fill in most of the blanks.

I took some running notes as I read through them. The end result reads like a peer review for a paper (minus any kind of "accept/reject" decision 😉). So, consider me "Reviewer 1". 😁

One comment I'll make ahead of time is that a lot of my comments boil down to, essentially, "wouldn't this problem vanish if the units could just compose?" And a huge selling point of V2 is that... the units can just compose. So I think many of my comments end up in the "already solved" bucket.

Slide 5

What does this example have to do with downcasting? Wouldn't you expect to get (km / h) by default when you divide km by h?

Slide 6

It looks like there's more highlighted text underneath the footer.

Slide 12

magnitude makes a not-so-pretty appearance in the compiler errors 😅

Still, I think this ties into my comments on slide 5: I would expect this to simply be (km / h) naturally. I think the root difference here is the philosophy of "no preferred units", which Au (for example) follows, and mp-units doesn't. I think, based on the text output (70 [5/18] m/s), that mp-units is converting to the "preferred" unit of m/s in the display. What I would expect from a "no preferred units" approach is that the quotient of the units km and h is the new unit (km / h).

In the typename from the compiler error, it looks like we get an "unknown coherent unit" of an "unknown dimension". Is this because downcasting is automatically looking up the "preferred" name of the unit with this dimension-and-magnitude, and calling it "unknown unit" if not?

The way I would state the problem with downcasting is this: it's a global registry for unit names. I think we should be suspicious of global registries both in general, and in this specific case. The alternative in a no-preferred-units framework is to simply form new "compound" units from constituent pieces, using named prefixes and arithmetic combinations. This gives us local reasoning, which is nice.

Side note: I was extremely puzzled by all of the ratio{-11, 11} and similar instances. Then I realized that the bases themselves were 21, 31, and 51... and then I realized that no, they're really 2l, 3l, and 5l, but 1 ("one") and l ("ell") are virtually indistinguishable in the font in the slides.

Slide 16

It's unfortunately true that magnitudes made types harder to understand in mp-units. However, no-preferred-units would provide a solution here in a similar way as for the above cases: the resulting unit would be (1 / km).

I think this philosophy is why even though Au uses essentially the same magnitude implementation, I can't recall the last time I've seen one show up in a compiler error.

Slide 20

This reminds me that actually understanding #427 is on my TODO list. 😁 I still suspect that trying to handle quantity "kinds" is scope creep, and that the effect of making the library more difficult to use will outweigh the prevention of bugs. However, I used to be much more confident of this viewpoint before I (superficially) followed the discussion in #427 --- it's moved my priors towards being more optimistic for kinds working out.

Slide 44

More and more over time, solution 3 (quantity references) just looks better and better to me.

Also, why did we jump from slide 22 to 44? 😅

Slide 30

Is this actual code?

speed avg_speed(length l, time t)
{
  return l / t;
}

auto res = avg_speed(120 * km, 2 * h);

Wouldn't we need to say speed auto, and so on? (I'm assuming speed is a concept, and length and time as well.)

Slide 36

Is "character" in-scope for a units library? That makes me a little nervous.

Slide 42

Here's one example for why I worry about kinds. The word "length" is overloaded between the "length, width, height" triad, and the "generic physical distance" meaning. And if we support kinds, we'll necessarily have both uses! This leads to a width being implicitly convertible to a length, but not vice versa, which I find confusing even as a "units library expert", which makes me worried about how the masses of end users will experience it.

Slide 54

I'm confused about recipes: how they work, what value they provide. Does this mean that we couldn't form a kinetic energy as (m * v) * v? Or m * (d * d) / (t * t)?

Slide 82

I'm confused about this: I thought the whole point of making width and height subdivisions was to prevent them from being compared?

Slide 90

Neat!

I hope this becomes the standard someday. I look forward to jettisoning the patent absurdity of (m / m) in the "standard" definition of radians (as seen on, e.g., slide 62).

Slide 109 -- 110

This is really the main point: V2 is a dramatic leap forward along a wide variety of dimensions --- really impressive stuff!

I do have lingering doubts about whether quantity kinds will do more good than harm. Perhaps only time will tell. I think it's quite clear that they're in the regime of diminishing returns (compared to plain vanilla dimensions-and-magnitudes), but how deep exactly is an open question.

[JohelEGP]

Slide 42

Here's one example for why I worry about kinds. The word "length" is overloaded between the "length, width, height" triad, and the "generic physical distance" meaning. And if we support kinds, we'll necessarily have both uses! This leads to a width being implicitly convertible to a length, but not vice versa, which I find confusing even as a "units library expert", which makes me worried about how the masses of end users will experience it.

This is why we have standards, documentations, and conventions. And comments in code and whatnot. Especially when the (English) language doesn't help. In this case, we're following ISO/IEC.

[mpusz]

Thanks for feedback!

Slide 5

What does this example have to do with downcasting? Wouldn't you expect to get (km / h) by default when you divide km by h?

Unfortunately, not. The downcasting-based implementation always had to normalize the unit type (coherent unit was chosen) to search for user-predefined types.

Slide 6

It looks like there's more highlighted text underneath the footer.

Yes, there is. Sorry. I didn't notice that when I generated slides somehow the code font was not loaded properly. I will check if I can fix it soon.

Slide 12

I think the root difference here is the philosophy of "no preferred units", which Au (for example) follows, and mp-units doesn't. I think, based on the text output (70 [5/18] m/s), that mp-units is converting to the "preferred" unit of m/s in the display. What I would expect from a "no preferred units" approach is that the quotient of the units km and h is the new unit (km / h).

This would not work with the downcasting facility as stated above. To make it work we always had to have a canonical form to compare ratios and find a user-provided type for such ratios.

Slide 16

However, no-preferred-units would provide a solution here in a similar way as for the above cases: the resulting unit would be (1 / km).

In V2, magnitudes are mostly hidden. They still show, however, in common units (i.e. km/h + m/s).

Slide 20

I still suspect that trying to handle quantity "kinds" is scope creep, and that the effect of making the library more difficult to use will outweigh the prevention of bugs. However, I used to be much more confident of this viewpoint before I (superficially) followed the discussion in #427 --- it's moved my priors towards being more optimistic for kinds working out.

The old approach didn't scale. The V2 is way better here.

Slide 44

More and more over time, solution 3 (quantity references) just looks better and better to me.

Yes, this was a good approach. The biggest problem was that there were only symbolic names for them which resulted in many collisions. In the new approach a user can choose verbosity for units (either full names or opt-in for symbols).

Also, why did we jump from slide 22 to 44? 😅

This an picture of an old slide I presented on CppCon 2021 and asked the audience to vote on the best solution. And I just noticed that the voting results are missing on the next slide. I really have to regenerate those slides soon.

Slide 30

Is this actual code?

It might be, assuming that the user (in any library) will predefine such types. And yes, you ar right, this is not what you get right away from mp-units, but it was not the point here. I tried to be generic as this slide is an introduction to present the issue on the next slide.

Wouldn't we need to say speed auto, and so on? (I'm assuming speed is a concept, and length and time as well.)

Yes, we will need auto if those were concepts. mp-units v2 does not expose such concepts though. To limit the number of definitions (and potentially further standardization effort) we have now QuantityOf<isq::length> concept which user can easily wrap a a length concept if such use case is needed.

Slide 36

Is "character" in-scope for a units library? That makes me a little nervous.

This is an experimental feature now. We are trying to get some experience and find out if it works or not. So far I had quite good results with it but I am determined to drop it in case we will find out that it introduces more problems than needed.

Slide 42

Here's one example for why I worry about kinds. The word "length" is overloaded between the "length, width, height" triad, and the "generic physical distance" meaning. And if we support kinds, we'll necessarily have both uses! This leads to a width being implicitly convertible to a length, but not vice versa, which I find confusing even as a "units library expert", which makes me worried about how the masses of end users will experience it.

As Johel mentioned, we are following the ISO standard here. This is also why I explicitly show how easy it is to add horizontal_length on the next slides. Also, to limit confusion I hope to be able to generate UML trees of quantities of the same kind, exactly like those on my slides, in the project's new documentation.

Slide 54

I'm confused about recipes: how they work, what value they provide. Does this mean that we couldn't form a kinetic energy as (m * v) * v? Or m * (d * d) / (t * t)?

Maybe it is easier to describe it on gravitational_potential_energy. The constraining recipe for it is mass * acceleration_of_free_fall * height. acceleration_of_free_fall is not just an acceleration, it has a special meaning and usage, thus by itself, it should not be implicitly convertible from acceleration. An explicit conversion is required in such case. As a result also gravitational_potential_energy will be able to be implicitly converted from an equation containing acceleration_of_free_fall, but only explicitly convertible from acceleration or its ingredients

This means that every derived quantity can be created only implicitly from ingredients that are implicitly convertible to ones provided its quantity expression/recipe. For all other cases an explicit conversion is required.

Please also note that as long as I can implicitly create energy from any kind of mass, length, and time, this will not work for its leafs. It is assumed that, for example, a mechanical_energy is a special kind of energy, and having just energy ingredients, it is not enough to determine if it is a mechanical_energy or active_energy. This is why again, an explicit conversion is required. Having additionally constraining recipes in "specialized" quantities of a kind, allows to implicitly construct them from ingredients of such recipe.

Slide 82

I'm confused about this: I thought the whole point of making width and height subdivisions was to prevent them from being compared?

Comparison, addition, and subtraction is required by the ISO 80000 and I try to follow it. It makes a lot use cases simpler without loosing too much safety. Could you please provide a specific example when this could be a safety issue?

width and height are not convertible to each other (implicitly and explicitly) which improves interfaces a lot.

Slide 90

I hope this becomes the standard someday. I look forward to jettisoning the patent absurdity of (m / m) in the "standard" definition of radians (as seen on, e.g., slide 62).

I hope as well. Important to notice here may be the fact that strong angles were the default in V1 but are not in V2. We want to model ISQ and SI as close as possible so we follow their definitions for angular units as well. To improve type safety I introduced angular and isq_angle systems.

Slide 109 -- 110

This is really the main point: V2 is a dramatic leap forward along a wide variety of dimensions --- really impressive stuff!

Thanks! It literally took me thousands of hours to end up with this design and implementation. I also got a great feedback and help from many contributors on the way there! 😃 Thank you all!!!

I do have lingering doubts about whether quantity kinds will do more good than harm. Perhaps only time will tell. I think it's quite clear that they're in the regime of diminishing returns (compared to plain vanilla dimensions-and-magnitudes), but how deep exactly is an open question.

Please play with (or at least review) the examples we have now. I didn't find any issues with them so far and they improve interfaces and code expressiveness a lot.

[mpusz]

I have just regenerated the slides, so hopefully they will now look correct.

[chiphogg]

Let's make this the "kinds discussion" thread! 😄 I think it'll be more coherent to split this off from my generic feedback.

Slide 42

Here's one example for why I worry about kinds. The word "length" is overloaded between the "length, width, height" triad, and the "generic physical distance" meaning. And if we support kinds, we'll necessarily have both uses! This leads to a width being implicitly convertible to a length, but not vice versa, which I find confusing even as a "units library expert", which makes me worried about how the masses of end users will experience it.

As Johel mentioned, we are following the ISO standard here. This is also why I explicitly show how easy it is to add horizontal_length on the next slides. Also, to limit confusion I hope to be able to generate UML trees of quantities of the same kind, exactly like those on my slides, in the project's new documentation.

ISO 80000 is a standard for units of measure, and this project aims to add units support to C++ --- another ISO standard. Thus, it's only natural that we should strive to follow ISO 80000.

I'm not convinced this reasoning is correct, though.

If a project wants to adhere to ISO 80000, it's an open question how much of that should be handled by the software, and how much should be handled "manually" or by other means. Of course, this question also applies to the very idea of a units library itself! A program using raw numeric types is perfectly valid (it's just a lot more effort to get right).

I think the value proposition for "layer 1" of a units library --- that is, "pure" quantity calculus, dimensions-and-magnitudes --- is a slam dunk for most use cases. It robustly prevents the most common and pernicious category of errors (namely, "right-dimension-wrong-magnitude"). What's more, the system is easy to learn and reason about, and as far as I know it never produces a wrong answer or a need to "fight" the system.

"Layer 2" --- that is, subdivision into "kinds" --- I'm less convinced about. It should be completely uncontroversial that we've entered the regime of diminishing returns. A hierarchy of kinds adds complexity for end users, and I expect that in practice, errors-of-kind are far less common (and still less damaging) than "vanilla" unit errors. So it's mainly a question of how deep into that regime we are, and whether the costs have begun to outweigh the benefits.

Why am I worried about the costs and complexity? Take unlib for one example. Support for "kinds" (called "tags" in that library) was an essential feature for that library, whose absence in other libraries was a dealbreaker. And yet, we have this passage:

Note that tags do not reflect all properties of their engineering counterparts. For example, dividing reactive power by voltage, which is untagged, will have the resulting quantity of current being tagged as reactive, which very likely won't make much sense. In these cases you will have to use a cast to make the library submit to your application domain's rules.

What this means to me is: "the system readily produces nonsense results, and you will routinely have to fight it". I think the root cause is a system of tags that gives useful results in certain cases --- e.g., it's satisfying that reactive power multiplied by time gives reactive energy! --- but which generalizes poorly outside of certain very special cases.

Again, this is compared to "bare" quantity calculus, which is mature, easily learned and understood, and never produces nonsense.

Now, tags are unlib's approach to kinds, not mp-units' approach. Maybe mp-units fares better. In fact, from reading the slides, I suspect it probably does! It seems like this is exactly the kind of use case which "recipes" are intended to address --- is that right?

If so, I still think there's the broader question of whether this novel system produces nonsense results in other cases. I think the only way to answer that is with the kind of accumulated experience that can only come from broad deployment, at scale, in diverse use cases. And this creates significant schedule risk, which I don't think has been called out before. V2's system of kinds is impressive and exciting, but it also didn't exist before 2023. I'm worried that we won't be able to accumulate the experience we'll need to answer that question in time for the committee to feel comfortable including it in C++26.

---

My goal in saying all this is not to argue that kinds are wrong, and that they should be removed. I don't actually know the answer to that. Rather, my goals are to point out that:

1. ISO 80000 is by no means a "requirement" for a standard C++ units library: what belongs in the library is whatever fares best on cost/benefit analysis for writing software.
2. The "kinds" layer is somewhere in the regime of diminishing returns.
3. The added complexity adds meaningful risk of failure to standardize for C++26, because it has far less implementation experience (essentially zero before 2023) than simple dimensions-and-magnitudes approaches.

Or, put more simply: there's an alternative design target for mp-units which does dimensions-and-magnitudes only, sacrificing strong types for widths, radii, etc. in order to reduce: a) the learning curve, and b) the risk from standardizing a system that has never been tried in software at scale. If this alternative gets rejected because we found that the "kinds" layer does pass a cost/benefit analysis, great! I could never have designed such a solution, and my hat's off to @mpusz for doing so (which is really impressive work no matter the ultimate outcome). I just want to make sure that we explicitly realize that there is a choice to be made.

[JohelEGP]

If kinds are still a layer in V2, the lower layer can still be proposed ahead.
It's worth considering reducing time spent working on kinds to start working on the proposals.

[chiphogg]

One thing to think about would be whether we could provide "bare" dims-and-mags to reduce schedule risk for C++26, but design it in a way that we could extend it with kinds later once people have more experience with them.

Of course, given that kinds are already in the current V2 codebase, that may end up being more work, which could create its own schedule risk. 😛

[mpusz]

ISO 80000 is a standard for units of measure

That is not correct. SI is the system of units. ISQ, defined by ISO 80000, is the system of quantities. SI is based on it (adds units to the quantities defined in the ISQ).

"Layer 2" --- that is, subdivision into "kinds"

Just to make it straight, we have two major features here. First, many quantities of the same kind (i.e. width, height, radius, etc). Yes, this is quite novel, and some may consider it less important. Second, different quantities of the same dimension (i.e. torque vs energy, frequency vs activity vs modulation rate). Those questions are often asked as they might produce issues if we allow those to be compared, added, or subtracted.

Take unlib for one example.

unlib provided incorrect, not scalable kinds support (similar to what we had in V1). V2 is much better.

"the system readily produces nonsense results, and you will routinely have to fight it"

Did you actually try it? I suggested you review our examples. Did you find any issues there where you had to fight with kinds?

I'm worried that we won't be able to accumulate the experience we'll need to answer that question in time for the committee to feel comfortable including it in C++26.

C++26 is gone already for us, even if we decided to go with units-only mode. To be able to be part of it, we should provide the first papers at least a year ago. I was told that by many ISO C++ Committee members already, including the LEWG chair. We have just 6 meetings to feature freeze C++26, which is not enough for any library of such scale and impact. I was not happy enough with the V1 design to propose it for standardization. The Downcasting Facility had too many issues when used in this domain. Also, we had no good way to construct quantities. V2 solves all of those and adds ISQ support.

Realistically, we should expect the standardization possibility in C++29. It gives us the time necessary to gather feedback and experience with the new library design. I hope to be able to finish the V2 version for gcc-12 by the C++ on Sea, and to put it on mainline (with support for all major compilers) before CppCon. Of course, any help is greatly appreciated.

[mpusz]

We should not strive to put "the thing" into C++ standard. We should try to create the best library that will address issues in the domain and be user-friendly at the same time. If we will succeed, we will get a lot of users. When we get a lot of users and feedback, the standardization process will be much easier for us. The last thing I want to be remembered for is to be the guy that put some crapy library in the C++ standard 😉

[chiphogg]

unlib provided incorrect, not scalable kinds support (similar to what we had in V1). V2 is much better.

Well, this is really encouraging to hear!

"the system readily produces nonsense results, and you will routinely have to fight it"

Did you actually try it? I suggested you review our examples. Did you find any issues there where you had to fight with kinds?

I haven't tried it, because I don't have a non-artificial use case for it. Basically all of my currently active C++ units use cases are at work, where we have our own units library and couldn't use mp-units even if we didn't.

My main goal in raising the issue was just to give something for people who are already using it to watch out for. Basically every piece of feedback I've received since then indicates that yes, V2 really does address the problems with kinds, and provides a coherent system which can actually work at scale. So, congrats on tackling such a thorny design problem!

[mpusz]

ACCU recordings are still not available, but today appeared my shorter talk on the same subject from the "using std::cpp 2023" conference in Madrid. Here is the link https://www.youtube.com/watch?v=3XSVCmWQklI.

[mpusz]

I am happy to hear that! 😃

[chiphogg]

I just got to the part where you use "deducing this". Does it mean we're bumping the minimum requirement to C++23?

[JohelEGP]

I doubt it. You'll see a lot of #if #elif to opt-into that on mp-units' side.

[chiphogg]

Ah... just got to the Q&A. Sounds like there are macros to keep C++20 compatibility in the meantime. Makes sense!

[mpusz]

We are using a macro in the library to provide portability with C++20:

https://github.com/mpusz/units/blob/4209ac20fc7feb897515f5ed055f61403012a4cc/src/core/include/mp_units/quantity_spec.h#L352-L364

[JohelEGP]

Here's the talk's link: https://www.youtube.com/watch?v=l0rXdJfXLZc.

Premieres in 12 days
August 11 at 14:00 UTC

[JohelEGP]

The talk's update was great.
V2 is really shaping up to be a great library.

[JohelEGP]

Slide 15:

That's #248.

[JohelEGP]

Slide 47: https://youtu.be/l0rXdJfXLZc?t=2402.
"Never say never."
We're getting there in terms of language support.
Now with static_assert supporting arbitrary compile-time std::strings.

[mpusz]

static_assert() is not a solution in most cases because it is checked too late (after name lookup is done and overload resolution is done).

[JohelEGP]

You're right.
Maybe with P2573R0 '= delete("should have a reason");'.

[JohelEGP]

Slide 67:
Does this still apply?
I think I've mentioned somewhere that,
e.g., force can be a vector or a scalar
(e.g. normal force 𝘍ₙ, or the component of a vector 𝘍ₓ).

[mpusz]

Force is always a vector quantity. Scalar representation can be used to represent a vector (with the default direction in mind). It is opt-in in the library right now to use scalars for vectors with the is_vector type trait.

[mpusz]

My latest and greatest talk from the C++ on Sea 2023 is now online: https://www.youtube.com/watch?v=eUdz0WvOMm0.

[mpusz]

And two more lightning talks:

• https://www.youtube.com/watch?v=q4hmTeu8BaY
• https://www.youtube.com/watch?v=RZSJJ4ySgtM

[JohelEGP]

I'm looking forward to more of that series.

[mpusz]

I planned to deliver more on CppCon but was finally too busy preparing the content for the conference and papers for ISO.
Also, I would probably need to redo Part I when/if I finish the support for vector quantities.

Also, I had a bug on my slides 😉