Quantity points arithmetics

[mpusz]

For quantities, we allow arithmetic between different quantity types:

quantity q = isq::height(1 * m) + isq::width(1 * m);    // results with `isq::length(2 * m)`

We had something similar for quantity points, but I am starting to think, if that is correct.

For example, for lengths, quantities represent a distance/delta between two points. Adding such deltas of length measured in different ways/dimensions makes sense and is required by the ISO 80000. Quantity points of length represent a distinct point in, for example, 3D space. The same point may have many representations from different origins in this 3D space, but they all still describe exactly the same point.

Subtracting two points of width gives a delta of width. However, what does it mean to subtract points of height and width or add a delta of width to the point of height?

quantity q1 = quantity_point{isq::height(1 * m)} - quantity_point{isq::width(1 * m)};    // results with ????
quantity_point qp1 = quantity_point{isq::height(1 * m)} + isq::width(1 * m);    // results with ????

I start to think that the above should not compile. Do you agree?

The above examples contained quantities from different branches of the length hierarchy tree. What about the same branch?

quantity q2 = quantity_point{isq::height(1 * m)} - quantity_point{isq::length(1 * m)};    // results with ????
quantity q3 = quantity_point{isq::length(1 * m)} - quantity_point{isq::height(1 * m)};    // results with ????
quantity_point qp2 = quantity_point{isq::height(1 * m)} + isq::length(1 * m);    // results with ????
quantity_point qp3 = quantity_point{isq::length(1 * m)} + isq::height(1 * m);    // results with ????

A similar question to the above might be if it should be possible to define a point of height with the origin being a point of length or vice versa?

inline constexpr struct zero_length final : mp_units::absolute_point_origin<mp_units::isq::length> {} zero_length;
inline constexpr struct zero_height final : mp_units::absolute_point_origin<mp_units::isq::height> {} zero_height;

quantity_point qp4 = zero_length + isq::height(1 * m);
quantity_point qp5 = zero_height + isq::length(1 * m);

Please let me know your thoughts.

[mpusz]

@burnpanck, you always cared for quantity points and had good ideas on how to support those. Your feedback is welcomed here.

[Spammed]

I usually understand 'height' and 'width' as quantities of different (spatial) dimensions.
Therefore, my answer would be 'no, not allowed' both times.

Only if the points are defined in a common (vector) space, you can determine (vector) distances or offset them with (vector) distances of this space.

However, one might be tempted to interpret the 'length' in the expression implicitly as 'belonging to' in each case:
quantity_point{isq::height(1 * m)} + isq::length(1 * m) == quantity_point{isq::height(2 * m)};
I suspect that would not be a good idea.

[mpusz]

Therefore, my answer would be 'no, not allowed' both times.

Yes, this is why I submitted this issue. I think that we need to fix a few things.

I suspect that would not be a good idea.

Right. isq::length represents a generic/unspecified length but not any length. We represent any length with kind_of<QS> (or just a unit), and I think the below should work:

quantity_point{isq::height(1 * m)} + 1 * m == quantity_point{isq::height(2 * m)};

A bit more interesting may be the following cases:

quantity_point{1 * m} + isq::height(1 * m) == ???; // point of isq::height or any length ?
quantity_point{isq::height(1 * m)} - quantity_point{1 * m} == ???; // quantity<isq::height[m]> ?

[mpusz]

So it seems that isq::height and isq::width should have a common type, compare with each other, be convertible, and be possible to add or subtract only in case of quantities but not points.

This is yet another reason to consider a redesign of the quantity_point that I mentioned in my last blog article.

[burnpanck]

I do care a lot about quantity points. However, in my opinion, the concept of quantity types is quite orthogonal. For me, the benefit of what we call "quantity type" (I still struggle a bit with that name) are a scheme of incrementally narrowing down the applicability. I think it should not matter here if we are talking about points or distances - if we decide that two related quantity specs are "compatible" then this also applies to their points, and vice versa.

Now what should be compatible with each other? I think we have some choice here. We want to disallow obviously wrong things. We want to allow practically useful things if they are unambiguous. If you want to know the boundary length of a rectangle, you end up summing height and width. There is only one way to do that, it is unambiguous. It is, because you are adding the length of those things. (That said, the last time I participated in the discussion about quantity types, we were still classifying "sibling types" like those as incompatible).

I don't think that quantity_point{isq::height(1 * m)} + isq::width(2*m) -> quantity_point{3*m} is any more surprising than than isq::height(1 * m) + isq::width(2 * m) -> isq::length(3 * m).

[mpusz]

@burnpanck, it is good to hear from you again 😃

(That said, the last time I participated in the discussion about quantity types, we were still classifying "sibling types" like those as incompatible)

It depends on what you mean by incompatible. We can't convert from isq::width to isq::height, but we can add them and the result will be isq::length.

if we decide that two related quantity specs are "compatible" then this also applies to their points, and vice versa

I have a hard time imagining what it means to subtract a point of isq::height from a point of isq::width 😕

[mpusz]

BTW @burnpanck, you still have a few PRs open. Will you have some time to finish them soon?

[mpusz]

I thought about this a bit more.

Let's analyze such a simple tree:

flowchart TD
    parent["parent (e.g., length)"]
    parent --- child["child (e.g., height)"]
    parent --- other_child["other_child (e.g., radius)"]

Loading

Delta (quantity)

The below is obvious and we have it like this for a long time. I put it here for reference:

static_assert(delta<child> + delta<child> == delta<child>);
static_assert(delta<child> - delta<child> == delta<child>);
static_assert(delta<child> % delta<child> == delta<child>);
static_assert(delta<child> + delta<parent> == delta<parent>);
static_assert(delta<child> - delta<parent> == delta<parent>);
static_assert(delta<child> % delta<parent> == delta<parent>);
static_assert(delta<child> + delta<other_child> == get_common_quantity_spec(delta<child>, delta<other_child>));
static_assert(delta<child> - delta<other_child> == get_common_quantity_spec(delta<child>, delta<other_child>));
static_assert(delta<child> % delta<other_child> == get_common_quantity_spec(delta<child>, delta<other_child>));
static_assert(delta<child> + delta<kind_of<parent>> == delta<child>);
static_assert(delta<child> - delta<kind_of<parent>> == delta<child>);
static_assert(delta<child> % delta<kind_of<parent>> == delta<child>);

Points

I think it is reasonable to say that in the case of points and deltas, the point quantity type should be preserved. For example, if I put a wheel on a box, I might get the height of the top of the wheel by adding its radius multiplied by 2.

static_assert(point<parent> + delta<child> == point<parent>);
static_assert(point<parent> - delta<child> == point<parent>);
static_assert(point<parent> + delta<parent> == point<parent>);
static_assert(point<parent> - delta<parent> == point<parent>);
static_assert(point<parent> + delta<kind_of<parent>> == point<parent>);
static_assert(point<parent> - delta<kind_of<parent>> == point<parent>);

static_assert(point<child> + delta<child> == point<child>);
static_assert(point<child> - delta<child> == point<child>);
static_assert(point<child> + delta<parent> == point<child>);
static_assert(point<child> - delta<parent> == point<child>);
static_assert(point<child> + delta<other_child> == point<child>);
static_assert(point<child> - delta<other_child> == point<child>);
static_assert(point<child> + delta<kind_of<parent>> == point<child>);
static_assert(point<child> - delta<kind_of<parent>> == point<child>);

The tricky part is what to do if we have points of other types:

static_assert(point<parent> - point<parent> == delta<parent>);
static_assert(point<child> - point<child> == delta<child>);
static_assert(point<child> - point<other_child> == ???);
static_assert(point<parent> - point<child> == ???);
static_assert(point<child> - point<parent> == ???);
static_assert(point<parent> - point<kind_of<parent>> == ???);
static_assert(point<child> - point<kind_of<parent>> == ???);
static_assert(point<kind_of<parent>> - point<parent> == ???);
static_assert(point<kind_of<parent>> - point<child> == ???);

I do not know a good answer to the above 7 cases. If you agree, I would like those not to compile.

[burnpanck]

I can agree with the proposed rules for mixed point and delta arithmetics: The basic "rule" leading to your proposed results are:

• point is strictly "stronger" than delta
• In such an operation, the "weaker" delta can pass through "explicit casting paths" to enable the operation

But for operations between two points, I would prefer if the results were consistent with the implicit casting rules. So if point<child> can implicitly convert to point<parent>, then the difference of the two should be delta<parent>. If they are not implicitly convertible, then the operation should not compile either.

Finally, if delta<child> - delta<other_child> == delta<some-common-spec> (i.e. find a common spec where both operands can be implicitly converted to), then I think the same should apply to points as-well.

[mpusz]

I would prefer if the results were consistent with the implicit casting rules. So if point can implicitly convert to point, then the difference of the two should be delta. If they are not implicitly convertible, then the operation should not compile either.

Ohh, I forgot to write about this as well. Yes, I think that converting between points should also not be enabled as they may describe different spaces. However, I might be wrong. In such a case, please do let me know.

I would prefer to be conservative here and extend the design if compelling use cases emerge.

[burnpanck]

Yes, I think that converting between points should also not be enabled as they may describe different spaces

If they were, then that reasoning should also apply to deltas. After all, we claim that deltas are differences between points in the same space. If we say child is a parent allows them to be mixed for delta operations, then I feel that should apply to point operations as-well.

[mpusz]

Yeah, I'm trying to wrap my head around this.

My mental model is that, for example, for 1-D lengths, points represent an axis that can't be rotated, and we can only move back and forth through it. For example, altitude has a vertical axis. If we want to add a delta diameter to points on the altitude axis, we first need to "rotate" the diameter to align with the altitude axis. As a result, we end up with another altitude. As you wrote, points are strictly "stronger" than deltas.

Now, if you have a vertical axis for altitude and another for horizontal length, trying to subtract or convert between points on those two is impossible. Also, a parent quantity is a more generic quantity that, again, may be an "unspelled" horizontal length or an axis in any other direction.

Deltas are different. They express the exact amount and can be "rotated" to align to any other quantity. However, they lose their character after rotation, and we look for a common, more generic quantity that describes both of them.

Of course, my mental model might be wrong, and please let me know in such a case.

[chiphogg]

• point is strictly "stronger" than delta

This seems reasonable to me too, at least as far as the quantity category goes. But I wanted to clarify that this is not true for the units: rather, all the usual rules for "common unit" must apply. So, for the example of a point of altitude and a delta of diameter: if the point-of-altitude is measured in meters, and the delta-of-diameter in cm, then we should get a point-of-altitude measured in cm.

I think this is pretty uncontroversial, but I wanted to lay it out explicitly.