Refining expression templates simplification rules

[mpusz]

For the next mp-units release, I would like to revise the expression template simplification rules. This was initially proposed by @anthonywilliams in Tokyo, and I think it makes a lot of sense.

Current state

Currently, the same identifiers on the expression template list are always simplified. This provides a few interesting side effects:

static_assert(is_of_type<m / km, derived_unit<si::metre, per<si::kilo<si::metre>>>>);
static_assert(is_of_type<m / m, one>);
static_assert(is_of_type<isq::length / isq::height, derived_quantity_spec<isq::length, per<isq::height>>>);
static_assert(is_of_type<isq::length / isq::length, dimensionless>);

This impacts the convertibility rules and decreases the safety of the library. I described this problem in detail in the P3045 "Dividing two quantities of the same kind" and "Arithmetic and compatibility of quantities of dimension one" chapters.

Proposed

Some entities should not be automatically simplified by default. We should be able to deal with units like m/m and expect them to appear if the km/m is supported as well. Also, isq::length / isq::length should be allowed to happen with the following semantics:

static_assert(implicitly_convertible(isq::length / isq::length, dimensionless);
static_assert(implicitly_convertible(isq::length / isq::height, dimensionless);
static_assert(implicitly_convertible(isq::length / isq::height, isq::length / isq::length);

static_assert(!implicitly_convertible(dimensionless, isq::length / isq::length);
static_assert(!implicitly_convertible(dimensionless, isq::length / isq::height);
static_assert(!implicitly_convertible(isq::length / isq::length, isq::length / isq::height);

static_assert(explicitly_convertible(dimensionless, isq::length / isq::length);
static_assert(explicitly_convertible(dimensionless, isq::length / isq::height);
static_assert(explicitly_convertible(isq::length / isq::length, isq::length / isq::height);

static_assert(!implicitly_convertible(isq::time / isq::time, isq::length / isq::length);
static_assert(!explicitly_convertible(isq::time / isq::time, isq::length / isq::length);
static_assert(castable(isq::time / isq::time, isq::length / isq::length);

Open questions

Dimensions

As stated in https://en.wikipedia.org/wiki/International_System_of_Quantities#Dimensional_expression_of_derived_quantities, the dimension of derived quantities is a product of powers of base dimensions, and a result is provided by a specific equation. Does this mean that, by definition, dimensions should always be simplified? Even if we allow forming a type like derived_dimension<isq::dim_length, per<isq::dim_length>> or derived_dimension<isq::dim_length, isq::dim_time, per<isq::dim_time>> in the framework, how would we print their symbols on the console?

[JohelEGP]

What about the idea of not simplifying anything by default?
Instead, simplification can happen at interface boundaries, where return types are explicitly specified.

quantity<one> f(quantity<length> l) { return l/l; }                 // Concrete quantity (non-template).
auto f(length auto l, length auto r) { return quantity(one, l/r); } // Quantity one (templated).

[mpusz]

Sure, that is the intent. Simplification will not happen automatically for units and quantity specs. The only question is what to do with dimensions.

Not-simplified entity will be convertible to a simplified one so it will happen exactly as you stated above. Also, I consider exposing a function like simplify(qs) and simplify(u) to force the simplification in place.

[chiphogg]

Very interesting proposal. The idea of not simplifying hadn't even occurred to me. I have always been suspicious of constructs such as "m / m" (one ridiculous "definition" of the units for radians), both in code and on pen-and-paper. But I can see the motivation and the utility here, and I'm curious how it would work in practice.

One negative consequence would be that the typenames printed in compiler errors would tend to become longer. I'm not sure how bad this would be in practice: many would be simplified by passing through an API, but many would not.

I do feel very strongly that something like "m / km" should not be simplified. (This is already the case in mp-units and Au, and I'm confident we got it right.) The units "m" and "km" are separate units. From a practical point of view, I really don't think we want to be reasoning about whether unit X is a prefixed version of unit Y (let alone whether they are both prefixed versions of some other unit!).

But then, if we take this for granted, and if we also continue gathering identical units to a single power, then "m / m" is treated differently than "m / km". This never bothered me before, but I do see the value in being consistent.

Question: I notice that all of the examples involve division. To be consistent, should we also avoid simplifying multiplication? Should multiplying two quantities of "m" result in "m * m" rather than "squared(m)"?

Question: Do we also now have order-dependence? Should "m *m / s" produce the same type as "m / s * m"? Will we also end up with things like "m / m * m / m * m"?

[mpusz]

Should multiplying two quantities of "m" result in "m * m" rather than "squared(m)"?

Well, we have no way to spell m * m or squared(m) in the result. Both in mp-units and Au, we end up with something pow<m, 2>, and I think it is fine.

[mpusz]

Do we also now have order-dependence? Should "m *m / s" produce the same type as "m / s * m"? Will we also end up with things like "m / m * m / m * m"?

I think that both of these should return the same type as a result.

[mpusz]

In our docs I described all the steps of expression templates processing. I think that only simplification step should not be done by default for most entities (besides dimensions). All the others (Ordering, Aggregation, Repacking) should still happen.

[anthonywilliams]

Hi, My implementation does not simplify: you can cast to simplified units, but "m/m" is not "1"

On 2024-06-24 15:45, Chip Hogg wrote: Question: I notice that all of the examples involve division. To be consistent, should we also avoid simplifying multiplication? Should multiplying two quantities of "m" result in "m * m" rather than "squared(m)"?

"m*m" is squared(m). m*m/m is squared(m)/m. In my implementation, that is power_kind<m,2,1> (+2, -1 => +1 overall)

Question: Do we also now have order-dependence? Should "m *m / s" produce the same type as "m / s * m"? Will we also end up with things like "m / m * m / m * m"?

In my implementation that is simplified to power_kind<m,3,2>. "m*m/s" is the same as "m/s*m". I think order dependence would lead to madness. Cheers, Anthony

[chiphogg]

So, are you basically gathering together all of the positive and negative powers? That makes sense.

How do you deal with rational powers?

[anthonywilliams]

On 24 June 2024 16:28:09 BST, Chip Hogg ***@***.***> wrote: So, are you basically gathering together all of the positive and negative powers? That makes sense. How do you deal with rational powers? -- Reply to this email directly or view it on GitHub: #582 (reply in thread) You are receiving this because you were mentioned. Message ID: ***@***.***>

At the moment I don't deal with rational powers, but making the positive and negative values rationals rather than integers isn't a big leap. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[mpusz]

We want the library to discriminate between length / length and time / time and make those castable to each other (two separate branches in the dimensionless quantity kind).

I tried to implement this, but I have some problems on the way.

Let's assume that we have a system of quantities with the following definitions:

inline constexpr struct path_length : quantity_spec<length> {} path_length;
inline constexpr struct distance : quantity_spec<path_length> {} distance;
inline constexpr struct period_duration : quantity_spec<time> {} period_duration;
inline constexpr struct frequency : quantity_spec<inverse(period_duration)> {} frequency;
inline constexpr struct speed : quantity_spec<length / time> {} speed;
inline constexpr struct velocity : quantity_spec<speed, position_vector / time> {} velocity;
inline constexpr struct acceleration : quantity_spec<velocity / time> {} acceleration;

Previously, the following resulted in the implicit conversions (we can call a function
taking a quantity on the RHS with an argument of the LHS below):

length / speed -> time                     // because: length / length * time -> time
distance / speed -> time                   // because: distance / length * time -> time
distance -> speed * time                   // because: distance -> length / time * time
velocity / acceleration -> time            // because: velocity / velocity * time -> time
velocity * time -> acceleration * time^2   // because: velocity * time -> velocity / time * time^2

The following resulted in the explicit conversion:

length / speed -> period_duration          // because: length / length * time -> period_duration
acceleration / velocity -> frequency       // because: velocity / time / velocity -> frequency

How the above should work with the lack of automatic simplifications?

[chiphogg]

Just to be clear: are you saying that the above examples are what happens today, and simply asking what we think they should be in this new world?

And when you say "I have some problems on the way", are you meaning that you're not sure what behavoiur we should want here?

[mpusz]

Yes, the above is the current behavior. It works because length / length or time / time is immediately simplified. When I disable the simplification, those stop working even though I think this is what users expect to work.

It is hard for me to find a consistent design. If we say that length / length should be distinct from time / time then this should be propagated to something like:

length / length * mass !=  mass * time / time

but that starts to be really hard to reason about in the generic code.

[rothmichaels]

Hmm, this does seem tricky as I agree users might expect those conversions. I'll have to think about it some more but a few initial thoughts:

Do you imagine we would have some simplify(...) that we could use to force simplification so users don't need to specify the type?

This reminds me of how you can make an API that takes a m or length depending if you want the API in easy-mode or safe-mode. I wonder if there is a way to apply a similar idea to this concept.

[mpusz]

Yes, I implemented simplify(...) already for quantity specifications, units, and references, but I do not think it should affect conversion rules. For me, "to simplify" means "to return the same in a simpler form (if possible)". If it is the same thing, then it should behave the same.

[mpusz]

I made it! All old and new tests are passing now :-)

Only the last few (hopefully minor) things to be fixed remained.

[rothmichaels]

Do you have a branch that disables simplification? I'd be curious to try some of my examples with that branch.

[mpusz]

I have those changes on my computer. However, without solving the above, most of the unit tests and systems definitions fail to compile, so I do not think there is any benefit in sharing that.

[mpusz]

While fixing the remaining issues I got the following error:

error: no match for ‘operator+’ (operand types are ‘const geographic::msl_altitude’ {aka ‘const mp_units::quantity_point<mp_units::reference<mp_units::isq::height, mp_units::si::metre>(), geographic::mean_sea_level()>’} and ‘mp_units::quantity<mp_units::reference<mp_units::derived_quantity_spec<mp_units::isq::distance, mp_units::isq::height, mp_units::per<mp_units::isq::distance> >, mp_units::derived_unit<mp_units::si::kilo_<mp_units::si::metre>, mp_units::si::metre, mp_units::per<mp_units::si::kilo_<mp_units::si::metre> > > >(), double>’)
[build]    63 |   return l.begin().alt + alt_diff * ((pos.dist - t.get_leg_dist_offset(pos.leg_idx)) / l.get_distance());
[build]       |          ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[build]       |                    |              |
[build]       |                    |              mp_units::quantity<mp_units::reference<mp_units::derived_quantity_spec<mp_units::isq::distance, mp_units::isq::height, mp_units::per<mp_units::isq::distance> >, mp_units::derived_unit<mp_units::si::kilo_<mp_units::si::metre>, mp_units::si::metre, mp_units::per<mp_units::si::kilo_<mp_units::si::metre> > > >(), double>
[build]       |                    const geographic::msl_altitude {aka const mp_units::quantity_point<mp_units::reference<mp_units::isq::height, mp_units::si::metre>(), geographic::mean_sea_level()>}

This is much harder to understand than the previous simplified error:

error: no match for ‘operator+’ (operand types are ‘const geographic::msl_altitude’ {aka ‘const mp_units::quantity_point<mp_units::reference<mp_units::isq::height, mp_units::si::metre>(), geographic::mean_sea_level()>’} and ‘mp_units::quantity<mp_units::reference<mp_units::isq::height, mp_units::si::metre>(), double>’)
[build]    63 |   return l.begin().alt + alt_diff * ((pos.dist - t.get_leg_dist_offset(pos.leg_idx)) / l.get_distance());
[build]       |          ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[build]       |                    |              |
[build]       |                    |              mp_units::quantity<mp_units::reference<mp_units::isq::height, mp_units::si::metre>(), double>
[build]       |                    const geographic::msl_altitude {aka const mp_units::quantity_point<mp_units::reference<mp_units::isq::height, mp_units::si::metre>(), geographic::mean_sea_level()>}

Are we sure we want to go this path?

[chiphogg]

Formatting makes these look almost identical without horizontal scrolling. Let me wrap to 80 characters.

After:

error: no match for ‘operator+’ (operand types are ‘const
geographic::msl_altitude’ {aka ‘const
mp_units::quantity_point<mp_units::reference<mp_units::isq::height,
mp_units::si::metre>(), geographic::mean_sea_level()>’} and
‘mp_units::quantity<mp_units::reference<mp_units::derived_quantity_spec<
mp_units::isq::distance, mp_units::isq::height,
mp_units::per<mp_units::isq::distance> >,
mp_units::derived_unit<mp_units::si::kilo_<mp_units::si::metre>,
mp_units::si::metre, mp_units::per<mp_units::si::kilo_<mp_units::si::metre> > >
>(), double>’) [build]    63 |   return l.begin().alt + alt_diff * ((pos.dist -
t.get_leg_dist_offset(pos.leg_idx)) / l.get_distance()); [build]       |
~~~~~~~~~~~~~ ^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[build]       |                    |              | [build]       | |
mp_units::quantity<mp_units::reference<mp_units::derived_quantity_spec<
mp_units::isq::distance,
mp_units::isq::height, mp_units::per<mp_units::isq::distance> >,
mp_units::derived_unit<mp_units::si::kilo_<mp_units::si::metre>,
mp_units::si::metre, mp_units::per<mp_units::si::kilo_<mp_units::si::metre> > >
>(), double> [build]       |                    const geographic::msl_altitude
>{aka const mp_units::quantity_point<mp_units::reference<mp_units::isq::height,
>mp_units::si::metre>(), geographic::mean_sea_level()>}

Before:

error: no match for ‘operator+’ (operand types are ‘const
geographic::msl_altitude’ {aka ‘const
mp_units::quantity_point<mp_units::reference<mp_units::isq::height,
mp_units::si::metre>(), geographic::mean_sea_level()>’} and
‘mp_units::quantity<mp_units::reference<mp_units::isq::height,
mp_units::si::metre>(), double>’) [build]    63 |   return l.begin().alt +
alt_diff * ((pos.dist - t.get_leg_dist_offset(pos.leg_idx)) / l.get_distance());
[build]       |          ~~~~~~~~~~~~~ ^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[build]       |                    |              | [build]       |
|              mp_units::quantity<mp_units::reference<mp_units::isq::height,
mp_units::si::metre>(), double> [build]       |                    const
geographic::msl_altitude {aka const
mp_units::quantity_point<mp_units::reference<mp_units::isq::height,
mp_units::si::metre>(), geographic::mean_sea_level()>}

Yep, that does seem like a significant usability regression.

Understandable compiler errors are a core strength of the library's design. Making compiler errors more complicated is a predictable, and significant, cost to deferring simplification. It buys us a small, but perhaps significant, refinement of our ability to distinguish quantities.

Is it worth the cost? I don't actually know. My viewpoint had previously always been that talking about "meters per meter" is transparent nonsense, that was destined to collapse as soon as anyone tried to express it in software. @anthonywilliams' idea --- that we can still collect same-sign powers, but defer collecting opposite-sign ones --- made me reconsider. It seems like it could actually work! At least, I haven't seen a robust counter-example yet.

So, meanwhile: how does the cost compare to the benefit? I think the added complexity and worse error messages outweigh the richer expressivity --- but not by much, and I'm highly uncertain about that. Nevertheless, I'm leaning towards continuing on this path, mainly because I'm really curious to see whether the idea stands up to widespread use at scale. 🙂 So either it won't work (which is fine, because we can revert it later), or it will work (which is also fine, because then I can give Au a clean "best" score on compiler error readability 😉).

[mpusz]

What even should be a common type returned from such or similar additions?

[mpusz]

because then I can give Au a clean "best" score on compiler error readability 😉

🤣