Operations on vector quantities

[mpusz]

I am in the process of improving the support for vector quantities. We have had many simplifications and errors in this subject so far, and we should try to improve here. The question here is how strict we should be.

Let's see the following example.

We were defining speed and velocity as

inline constexpr speed final : quantity_spec<length / time> {} speed;
inline constexpr velocity final : quantity_spec<speed, position_vector / duration> {} velocity;

which was a simplification, wrong, and inconsistent with ISQ definitions. ISQ defines them in the following way:

inline constexpr velocity final : quantity_spec<displacement / duration> {} velocity;
inline constexpr speed final : quantity_spec<norm(velocity)> speed {};

Well, velocity is actually defined in terms of delta position_vector, but that is a displacement and should be fixed in our definitions.

Note that speed and velocity are not in the same tree, and the real definition order (dependency) is reversed to what we had before.

Moreover, our flagship example for many years looked like this:

constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,
                                                QuantityOf<isq::time> auto t)
{
  return d / t;
}

quantity height = isq::height(20 * m);
quantity time = 5 * s;
quantity speed = avg_speed(height, time);

This is a simplification as length does not necessarily have to describe a displacement. What kind of speed will I get by dividing the height of the building by time? The building does not move or change its height. But this is how we are used to do it in the engineering.

Of course, if I drop a rock from the top of the roof and observe it falling down, I may use the height of this building to measure the displacement of the rock on its way down.

Also, a displacement is a vector quantity and should be described by the vector representation type. However, when we want to get speed and not velocity, we should not care.

To summarize, a proper function template should look like:

constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<norm(isq::displacement)> auto d,
                                                QuantityOf<isq::duration> auto t)
{
  return d / t;
}

and we should call it with:

quantity speed = avg_speed(quantity_cast<norm(isq::displacement)>(height), time);

The question is, is that not too much? Does requiring a quantity_cast to a norm(displacement) not sacrifice usability for physical safety/correctness too much? What can we do to improve that?

[JohelEGP]

The first signature still looks good.
It's still a valid formula of speed.
The onus is then on the author of the function
to cast the length to whatever QuantityOf<isq::speed> requires.

[mpusz]

Well, we could argue if that is a valid formula. In the link you provided, it is explicitly stated that d is a "distance covered" which is different from the static height of the building 😉

But yes, we could implement this as well as:

constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,
                                                QuantityOf<isq::time> auto t)
{
  return quantity_cast<norm(isq::displacement)>(d) / t;
}

This makes it easy to use but less correct in the physical sense.

[mpusz]

I would like to mention that without introducing norm, vector_product, and scalar_product, it is nearly impossible to make any vector quantities like (velocity, acceleration, force, moment of force) work correctly and resemble their physical properties.

[mpusz]

We also probably should refactor our tree of quantities of kind length to something like:

flowchart TD
    length["<b>length</b><br>[m]"]
    length --- width["<b>width</b> / <b>breadth</b>"]
    length --- height["<b>height</b> / <b>depth</b> / <b>altitude</b>"]
    width --- thickness["<b>thickness</b>"]
    width --- diameter["<b>diameter</b>"]
    width --- radius["<b>radius</b>"]
    radius --- radius_of_curvature["<b>radius_of_curvature</b>"]
    length --- path_length["<b>path_length</b>"]
    path_length --- distance["<b>distance</b>"]
    distance --- displacement["<b>displacement</b><br>{vector}"]
    distance --- radial_distance["<b>radial_distance</b>"]
    radial_distance --- position_vector["<b>position_vector</b><br>{vector}"]
    length --- wavelength["<b>wavelength</b>"]

Loading

The primary changes are:

1. norm(displacement) is a distance, but not every distance is a norm(displacement). Thanks to this, if we will have a distance quantity, we will be able to call avg_speed(norm(isq::displacement)(distance), time) with no need for quantity_cast.
2. norm(position_vector) could be considered as radial_distance. Please let me know if you think this is incorrect. We can move position_vector directly under distance, but that will require a quantity_cast to convert norm(position_vector) to radial_distance or vice versa.
3. Not that long ago, I thought that position_vector should be a leaf from displacement to express that position_vector can be modeled as a displacement from the origin. However, position_vector does not imply relocation, which is inherent to displacement.

[Spammed]

Perhaps each vectorial quantity should be named '..._vector'.
So 'displacement_vector' instead of 'displacement' and 'velocity_vector' instead of 'velocity'?
'speed = norm(velocity_vector)' is perhaps more natural than 'speed = norm(velocity)'.

[mpusz]

We can't rename ISQ quantities. Their names are standardized.

A user can always provide an alternative name with:

constexpr auto velocity_vector = velocity;

Also, a helper for norm(isq::displacement) can be provided:

constexpr auto displ_norm = norm(isq::displacement);

With the above the avg_speed could be called as:

avg_speed(displ_norm(distance), time);

[mpusz]

Looking at the tree above and discussing the problem with automotive experts in the ISO C++ Committee who know mp-units really well already, we decided to redefine speed to:

inline constexpr velocity final : quantity_spec<displacement / duration> {} velocity;
inline constexpr speed final : quantity_spec<path_length / duration> {} speed;

It is inconsistent with ISQ but is more correct and useful. velocity is always a temporary speed vector attached to the path we travel. The magnitude of it gives us a temporary speed. However, we often need to calculate the speed of the entire path. This is why I believe that path_length / duration is a better definition here.

As a result, we still have to quantity_cast from height, but that is exactly why we have a quantity_cast in the library. If someone wants to calculate speed, then a path_length or distance should be provided.

To summarize, our new avg_speed definition may be:

constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::path_length> auto d,
                                                QuantityOf<isq::duration> auto t)
{
  return d / t;
}

norm(isq::displacement) can still be provided if needed as it is implicitly convertible to isq::path_length.

[mpusz]

Now the question is, does passing a norm(isq::position_vector) make any physical sense? It will compile, but it probably is not a correct behavior.

Despite radial_distance being defined as :

distance (item 3‑1.8), where one point is located on an axis or within a closed non self-intersecting curve or surface

Maybe it should not be in the same but parallel branch to distance. Maybe radial_distance is actually not a distance? Or maybe it is, but not every distance and path_length make sense as an argument to speed? distance does not always imply a relocation of the object, which is needed to talk about speed. I am lost again now 😢

Any thoughts...

[Spammed]

What exactly does the arrow in the tree represent?
If an arrow means 'The lower is a specialized form of the upper'?
A specialization, I think, does not change the character and therefore scalars and vectors must be kept in separate trees.
Oh dear!

[mpusz]

Yes, it means exactly that.

Separate tree is not an option. Displacement and position vector are still quantities of length and they are measured in metres.

I considered putting them in a separate branch (this is exactly what we have until 2.4.0) but I think it's wrong as well. There are at least two reasons for that:

1. I think that saying that a 3D length is a more specialized version of length is a perfectly fine statement. This applies to position_vector being a 3D version of radial_distance, and displacement being a 3D version of distance travelled. Of course vectors can also have other dimensionality than 3D.

2. magnitude(displacement) is distance_traveled which is a more specialized version of distance. Even though in most cases we can't directly convert a 3D displacement to distance because of representation type incompatibility, the magnitude of such displacement can be perfectly converted to distance. Which is exactly what we want to achieve here.

[mpusz]

How about:

constexpr auto distance_traveled = norm(isq::displacement);

constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<distance_traveled> auto d, QuantityOf<isq::time> auto t)
{
  return d / t;
}

?

We can also consider adding distance_traveled to the length hierarchy between distance and displacement.