More affine spaces

[mpusz]

We have long supported The Affine Space abstraction. We have quantity and quantity_point.

Abstractions in ISQ

However, it turns out that is not the only abstraction level where we observe affine spaces. When we look closer at ISQ, we can see some examples as well.

height and altitude

• adding two altitudes does not make sense,
• subtracting altitude from height does not make sense as well,
• subtracting height from altitude is an altitude,
• adding height and altitude is an altitude.

Those are provided as aliased quantities in the ISQ.

displacement and position_vector

• adding two position_vectors does not make sense,
• subtracting position_vector from displacement does not make sense as well,
• subtracting displacement from position_vector is a position_vector,
• adding displacement and position_vector is a position_vector.

Those are separate quantities in the ISQ.

duration and time

• adding two times does not make sense,
• subtracting time from duration does not make sense as well,
• subtracting duration from time is time,
• adding duration and time is time.

time is not defined at ISQ at all (even though it is mentioned in Part 1 as a base quantity and referred to in some parts as defined in ISO 80000-3).

What to do?

Now the question is, what can/should we do with it?

1. As of today, a user can add two altitudes or position_vectors. The same applies to one of their subtractions. Should we disallow that?
2. Should we provide a different type as a result of subtraction of the same types (isq::altitude(4 * m) - isq::altitude(2 * m) -> isq::height(2 * m))?
3. Should the common_type of altitude and height be altitude?
4. Should we restrict altitude to be used only with quantity_point and height for quantity? This will automatically solve all the above math problems, as this has already been modeled in the library. However, we can't do arithmetic on quantity_point. If there is an operation that requires a point (e.g., usage of position_vector in moment_of_force), we would need to do qp.quantity_from_zero(). However, this should also return a quantity of displacement (and not position_vector), which will violate the requirements of the equation of moment_of_force.

Note 1: The above means that we need to diverge from ISQ and define altitude as a different quantity than height.

Note 2: Looking at the hierarchy tree provided in another thread #646 (comment), we can see that it does not allow doing arithmetics on vector quantities of displacement and position_vector as those do not share a common node that would also be of a vector type. So we need to think about how to provide both:

• proper conversion rules,
• proper arithmetic.

[mpusz]

This tree could provide a proper definition for all the quantities of kind length:

flowchart TD
    length["<b>length</b><br>[m]"]
    length --- width["<b>width</b> / <b>breadth</b>"]
    length --- height["<b>height</b> / <b>depth</b>"]
    height --- altitude["<b>altitude</b><br>{point_for&lt;height&gt;}"]
    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, point_for&lt;displacement&gt;}"]
    length --- wavelength["<b>wavelength</b>"]

Loading

Still, we need to decide what to do with those. How can we benefit from those in the library?

And I always thought that the tree for length is one of the simplest ones we deal with... 😱