V2 `quantity_point`

[mpusz]

I don't think the "offset" should be part of the unit, but rather the quantity (this is the main beef I have with my favourite units library in python, pint, see my comment here). The main argument is that, as soon as units appear in a compound expression, the offset immediately loses it's meaning (think for example the temperature coefficient of a resistor in kOhm/°C; obviously, that can only refer to temperature differences measured in °C, and there is simply no reasonable meaning to the "offset" of that quantity).

That said, it may make sense to define an implicit "offset" implied by the unit when describing a quantity point (e.g. a thermodynamic temperature) without explicitly specifying a reference point.

I also think we should really consider that information the "point of reference", not an "offset" - that one only appears between related quantities. But then, I have never really worked with quantity equations (and I don't have access to the ISO-80000 standard).

In the end, it would be great if the library would not only work for ISO thermodynamic temperatures, but also custom quantity points. Specifically, while the standard only endorses using °C to specify temperatures with respect to the "Celsisus temperature reference point", C++ programs may have a need to work with "unendorsed" combinations for efficiency reasons. As a specific example, we use this library on an embedded device employing a temperature sensor whose output is an 16 bit integer where zero corresponds to the temperature point -45 °C, and an increment of one corresponds to a temperature change of 0.01 °C. With #232, I can fully embed this information in the quantity_point and work with the original representation. However, I can also do computation with a floating point representation where the point of reference is still - 45 °C, but now I use SI °C for the scaling. Or, I can convert to the standard Celsius temperature reference point and continue to work with 0.01 °C increments, all in integer arithmetic.

Another use-case to consider is the glide-computer example, with different ways to express height/elevation, all using units of m and/or km.

Originally posted by @burnpanck in #391 (comment)

[mpusz]

I also think we should really consider that information the "point of reference", not an "offset"

That is more accurate.

where zero corresponds to the temperature point -45 °C, and an increment of one corresponds to a temperature change of 0.01 °C.

So the formula of this quantity Q should be something like Q = 𝘵 × 0.01 - 45 °C, where 𝘵 is Celsius temperature. By specifying the factor of 0.01 to 𝘵, and the point of reference -45 °C, you should be able to do the same with this V2 framework.

Originally posted by @JohelEGP in #391 (comment)

[mpusz]

That said, it may make sense to define an implicit "offset" implied by the unit when describing a quantity point (e.g. a thermodynamic temperature) without explicitly specifying a reference point.

In the current design, the quantity_point has access point_origin, quantity_spec, and a unit. In theory, any or all of them can introduce an offset for quantity_point arithmetic needs. It is up to us to specify what has sense and what does not. The problem with handling Celsius via quantity_spec is that with the current design, we cannot easily restrict a specific unit for a specific quantity. So both thermodynamic_temperature and Celsius_temperature can take K and deg_C as a unit. Even if we introduce some way to enforce such restrictions for those specific quantities similar problems will appear with all the derived quantities, like the mentioned temperature coefficient of a resistor in kOhm/°C.

[mpusz]

In the end, it would be great if the library would not only work for ISO thermodynamic temperatures, but also custom quantity points.

Sure, I totally agree. This is what I used for testing but still didn't have enough time to make it an official example or unit test:

  constexpr auto room_reference_temperature = quantity_point{21 * isq::Celsius_temperature[deg_C]};
  constexpr auto temperature_controller_delta = 3 * isq::Celsius_temperature[deg_C];

  constexpr quantity_point<isq::Celsius_temperature[deg_C], room_reference_temperature> room_default{0};
  constexpr quantity_point<isq::Celsius_temperature[deg_C], room_reference_temperature> room_low = room_default - temperature_controller_delta;
  constexpr quantity_point<isq::Celsius_temperature[deg_C], room_reference_temperature> room_high = room_default + temperature_controller_delta;

  static_assert(room_low.relative() == -3 * isq::Celsius_temperature[deg_C]);
  static_assert(room_low.relative() == -3 * isq::thermodynamic_temperature[K]);
  static_assert(room_default.relative() == 0 * isq::Celsius_temperature[deg_C]);
  static_assert(room_default.relative() == 0 * isq::thermodynamic_temperature[K]);
  static_assert(room_high.relative() == 3 * isq::Celsius_temperature[deg_C]);
  static_assert(room_high.relative() == 3 * isq::thermodynamic_temperature[K]);

  static_assert(room_low.absolute() == 18 * isq::Celsius_temperature[deg_C]);
  // static_assert(room_low.absolute() == (273.15 + 18) * isq::thermodynamic_temperature[K]);
  static_assert(room_default.absolute() == 21 * isq::Celsius_temperature[deg_C]);
  // static_assert(room_default.absolute() == (273.15 + 21) * isq::thermodynamic_temperature[K]);
  static_assert(room_high.absolute() == 24 * isq::Celsius_temperature[deg_C]);
  // static_assert(room_high.absolute() == (273.15 + 24) * isq::thermodynamic_temperature[K]);

  static_assert(room_high - room_low == 6 * isq::Celsius_temperature[deg_C]);
  static_assert(room_high - room_low == 6 * isq::thermodynamic_temperature[K]);
  static_assert((room_high - room_low)[K] == 6 * isq::Celsius_temperature[deg_C]);

The commented out code still does not work but I think it should.

[mpusz]

Another example I prepared while working on V2 quantity_point was:

  struct mean_sea_level : absolute_point_origin<isq::height> {};

  constexpr quantity_point<isq::height[m], mean_sea_level{}> ZRH_ground_level{432 * isq::height[m]};
  constexpr quantity_point<isq::height[m], mean_sea_level{}> GDN_ground_level{149 * isq::height[m]};
  constexpr quantity_point<isq::height[m], ZRH_ground_level> ZRH_afe{200 * isq::height[m]};
  constexpr quantity_point<isq::height[m], GDN_ground_level> GDN_afe{450 * isq::height[m]};
  static_assert(ZRH_afe.absolute() == 632 * isq::height[m]);
  static_assert(GDN_afe.absolute() == 599 * isq::height[m]);
  static_assert(GDN_afe - ZRH_afe == -33 * isq::height[m]);
  static_assert(GDN_ground_level - ZRH_ground_level == -283 * isq::height[m]);
  static_assert(ZRH_afe - GDN_ground_level == 483 * isq::height[m]);

[mpusz]

That looks all pretty cool to me, and I especially like directly specifying the reference point as quantity_point NTTP template argument, e.g. as in constexpr quantity_point<isq::height[m], ZRH_ground_level>.

The only place where I tend to disagree are the .absolute() accessors. To me, I lack a clear explanation what that would semantically do. q.relative() is easy: It is the same as q - q.origin_point. q.absolute() doesn't mean anything to me. A potential definition would be q.absolute() == q - q.ultimate_origin_point, and we could reasonably require that ultimate_origin_point is one arbitrary point that is the same for all quantity_points that are interconvertible. While this doesn't fully specify ultimate_origin_point, the only reasonable choice for thermodynamic temperatures would be (thermodynamic) absolute zero, so we would have your commented out variants correct instead, and the currently passing static_asserts would fail instead: room_low.absolute() == isq::thermodynamic_temperature(237.15+18, K) == isq::Celsius_temperature(237.15+18, deg_C). That said, we could also just leave .absolute out of the initial interface. (In fact, given the q.relative() == q - q.origin_point equivalence, we could also leave the .relative out of the interface).

Why cannot we have both X == isq::Celsius_temperature(18, deg_C) and X == isq::thermodynamic_temperature(273.15 + 18, K), for any hypothetical X? It is the same argument why we cannot have Y == isq::radius(2, m) and Y == isq::diameter(1, m) for any hypothetical Y: In both cases, we may interpret the ISO 80000 standard for the two quantities to be "equal". However, as we have seen, it turns out that this is at odds with the mathematical rules of standard operations when applied between quantities that aren't of equal (again; we lack a good name to to describe that equivalence class/concept): If we define isq::radius(2, m) == isq::diameter(1, m), then there will be no reasonable definition of isq::radius(2, m) + isq::length(1, m) that will preserve associativity and commutativity - that being unacceptable, the only option is to disallow it completely. The exact same happens for the temperatures: If we define isq::Celsius_temperature(0, deg_C) == isq::thermodynamic_temperature(273.15, K), then there is no reasonable definition of 2*(isq::Celsius_temperature(0, deg_C) + isq::thermodynamic_temperature(0, K)) (unless you consider 2*isq::Celsius_temperature(0, deg_C) == isq::Celsius_temperature(273.15, deg_C) reasonable). Furthermore, there is no reasonable definition to isq::thermodynamic_temperature(5, K) + imperial::Fahrenheit_temperature(9, deg_F).

For ISO 80000, mixed quantity operations aren't an issue, as it doesn't talk about mathematical operations between quantities at all as far as I know (though I don't know ISO 80000 well). For a library intent on modelling physical relations, it is however. This is why essentially all quantity libraries in all languages I know of discard those special equalities in their "normal mode" and sometimes provide special ways to opt-in into those equalities (e.g. astropy's equivalencies, mp-units' quantity_points, etc...).

Originally posted by @burnpanck in #391 (comment)

[mpusz]

Here is some more data to understand how it is currently defined:

https://github.com/mpusz/units/blob/2cf736a1e685457adf0e6e4b746f406c16a53c00/src/core/include/mp_units/quantity_point.h#L58-L70

https://github.com/mpusz/units/blob/2cf736a1e685457adf0e6e4b746f406c16a53c00/src/core/include/mp_units/quantity_point.h#L117-L128

[mpusz]

quantity_points have their own compatibility rules. Two quantity points are considered to be compatible if they are specified in terms of the same absolute_point_origin, which determines the beginning of the scale for all measurements. For example, you can do all the arithmetic and comparisons on all quantity_points specified in terms of mean_sea_level absolute point origin. It doesn't matter if mean_sea_level is a point origin of a current quantity_point or if it is the point origin of our point origin. In every case, those are considered compatible. I think that is exactly what you mean by the ultimate_origin_point, right?

absolute_point_origin specifies a value zero on our scale, and I do not care if it is an actual 0 or not. In fact, I do not know what the correct altitude for means_sea_level is, and I shouldn't care. But because of the fact I do not know this specific altitude I cannot subtract a quantity_point defined (potentially transitively) in terms of mean_sea_level with another one of the same quantity but a different absolute origin (i.e., the center of the Sun).

q.relative() is easy: It is the same as q - q.origin_point

I do not think that it should work this way. Every quantity_point stores its relative "distance" from the current origin, which does not have to be the absolute/ultimate one. This allows us to often store much smaller runtime values while a huge offset may be represented as a type. Like in the first example, I would prefer room_high to just store a value 3 rather than 24.

The only place where I tend to disagree are the .absolute() accessors. To me, I lack a clear explanation what that would semantically do

absolute() always provide a "distance" from the absolute_point_origin even if our current quantity_point is specified in terms of another point_origin (i.e. ZRH altitude).

[mpusz]

I believe that a unit should be orthogonal to a quantity_point. 18 * isq::Celsius_temperature[deg_C] and (273.15 + 18) * isq::thermodynamic_temperature[K] specify exactly the same temperature point expressed in different units. This is why I believe that the "offset" of 273.15 should be used only when converting a unit of a specific quantity_point and not be the source to form a totally different hierarchy of quantity_points.

As I stated above I would prefer this offset to be applied to a unit rather than quantity_spec as technically we can express both thermodynamic_temperature and Celsius_temperature in both K and deg_C.

[mpusz]

If we define isq::Celsius_temperature(0, deg_C) == isq::thermodynamic_temperature(273.15, K), then there is no reasonable definition of 2*(isq::Celsius_temperature(0, deg_C) + isq::thermodynamic_temperature(0, K)) (unless you consider 2*isq::Celsius_temperature(0, deg_C) == isq::Celsius_temperature(273.15, deg_C) reasonable). Furthermore, there is no reasonable definition to isq::thermodynamic_temperature(5, K) + imperial::Fahrenheit_temperature(9, deg_F).

I am not sure if that is true. isq::Celsius_temperature[deg_C](0) should not be the same as isq::thermodynamic_temperature[K](273.15) those are quantities and not quantity_points. For quantities, the following should be true:

static_assert(isq::Celsius_temperature[deg_C](42) == isq::thermodynamic_temperature[K](42));

When we are talking about quantity_points then the following should be true:

quantity_point{isq::Celsius_temperature[deg_C](42)} == quantity_point{isq::thermodynamic_temperature[K](273.15 + 42)}

The above should be implemented by applying an offset while converting a unit/quantity_spec from one to another.

[mpusz]

For ISO 80000, mixed quantity operations aren't an issue, as it doesn't talk about mathematical operations between quantities at all as far as I know (though I don't know ISO 80000 well).

https://www.iso.org/standard/64973.html 😉 Although, I still have to carefully study it...

[mpusz]

Maybe to reword this explicitly:

1. I believe that the best solution is to specify an offset in the unit definition:

   inline constexpr struct degree_Celsius : named_unit<basic_symbol_text{"°C", "`C"}, kelvin, offset<-mag<273150> * milli<kelvin>>> {} degree_Celsius;

2. Such offset should be applied only when converting units of quantity_point and not for casting a unit of a quantity.

3. Trying to follow blindly what ISO 80000 provides and specify offset in the quantity_spec definition is really problematic as we do not mention units in quantity_spec definitions, so there is no way to tell what 273.15 means. Such an offset could be provided as a standalone customization point (i.e. non-member function). The next issue with this approach would be the need to limit K only for thermodynamic_temperature, and deg_C for Celsius_temperature:

   inline constexpr struct kelvin : named_unit<"K", isq::thermodynamic_temperature, not_for<isq::Celsius_temperature>> {} kelvin;
   inline constexpr struct degree_Celsius : named_unit<basic_symbol_text{"°C", "`C"}, kelvin, only_for<isq::Celsius_temperature>> {} degree_Celsius;

   And at this point, we will realize that we have to add the support for the Fahrenheit scale as well... That is a lot of strange hacks to make one quantity work.

Please let me know if I am missing something here or if my logic is incorrect.

[burnpanck]

Ok, many things to discuss here, so I'll start from the top.

[burnpanck]

quantity_points have their own compatibility rules. ... I think that is exactly what you mean by the ultimate_origin_point, right?

Agreed. It's up to us to define those compatibility rules, but I always ask for our C++ objects to model semantics of physical objects. For quantity_point I like to take it to model of a "point" in an abstract space. We may describe that point by agreeing on some reference point, and then use our usual physical quantity concept to describe the distance. There are an infinite number of options to chose a reference point, from which we derive infinite number of descriptions of the very same point; these are equivalent representations of the same semantic point. This is not much different from quantities: We can describe the average height of a human, which is an abstract physical length (a quantity), using either a reference length of "cm", "in" or "m". All those descriptions are different combinations of numbers and units, yet they describe the same physical length (in this case, more specifically a height). This is what we want to model with "compatibility" here, and the algorithm you have described involving a chain of point-origins ending in an ultimate_point_origin == absolute_point_origin does model that correctly.

q.relative() is easy: It is the same as q - q.origin_point

I do not think that it should work this way.

This wasn't intended as an instruction for how it should be implemented. It is just characterisation of the semantics of the q.relative() operation, in that the result should be "as-if". q.relative() is a C++ expression that we made up. We cannot discuss if it is "correct" or not, unless we have a specification of what it should do. By describing that specification using physically relevant concepts (both q and q.origin_point are again semantically "points in an abstract space"), I constrain q.relative() to physically consistent with whatever q.origin_point is specified to (assuming we have agree to that - shall mean "measure" distance projected onto the "positive direction" embodied in that abstract space).

absolute() always provide a "distance" from the absolute_point_origin

This is just q - q.absolute_point_origin in words, which is fine for me. I slightly prefer the name ultimate_point_origin though, because it is the ultimate end of the reference chain, but that point is usually still incidental and not an "absolute", objective origin. There is neither a green line passing from north to south through Greenwich, nor do the cliffs in portugal expose a red horizontal line when the sea is below MSL. It just so happens that we all agree to refer to those lines, but it is actually very difficult to describe the location of that line by phone to a martian.

So far I fully agree with the semantics you have described. In the original post, the disagreement came with the "values" you provided for room_low.absolute(). Let me discuss that further down.

[JohelEGP]

3. The next issue with this approach would be the need to limit K only for thermodynamic_temperature, and deg_C for Celsius_temperature:

Why do this? ISO 80000 permits mixing them.