Ideas for new quantity and quantity point syntax

[mpusz]

As stated in my last blog post, we are considering changing the way how do we spell points in mp-units.

Let's discuss various options for new syntax here.

I thought about it for a while, and this is what I ended up with

How the user's code converts to generated types

• Quantity specifications

constexpr QuantitySpec auto qs1 = isq::height;          // -> isq::height
constexpr QuantitySpec auto qs2 = delta<isq::height>;   // -> delta<isq::height>
constexpr QuantitySpec auto qs3 = point<isq::height>;   // -> point<isq::height>

• Quantity specifications are not references

// constexpr Reference auto ref = isq::height;          // Compile-time error
// constexpr Reference auto ref = delta<isq::height>;   // Compile-time error
// constexpr Reference auto ref = point<isq::height>;   // Compile-time error

• Associated units are references

constexpr Reference auto ref1 = si::metre;              // -> si::metre

I propose that we can put a reference in delta<> and point<> as well:

constexpr Reference auto ref2 = delta<si::metre>;       // -> delta<si::metre>
constexpr Reference auto ref3 = point<si::metre>;       // -> point<si::metre>
constexpr Reference auto ref4 = point<si::metre, mean_sea_level>;  // -> point<si::metre, mean_sea_level>

• Typed quantities joint with units are references

From the beginning of mp-units 2.0 we had the QuantitySpec[Unit] -> Reference rule.

constexpr Reference auto ref5 = isq::height[m];         // -> delta<isq::height, si::metre>
constexpr Reference auto ref6 = delta<isq::height>[m];  // -> delta<isq::height, si::metre>
constexpr Reference auto ref7 = point<isq::height>[m];  // -> point<isq::height, si::metre>

The below follows the above proposal of putting a reference in delta<> and point<>

constexpr Reference auto ref8 = delta<isq::height[m]>;  // -> delta<isq::height, si::metre>
constexpr Reference auto ref9 = point<isq::height[m]>;  // -> point<isq::height, si::metre>
constexpr Reference auto ref10 = point<isq::height[m], mean_sea_level>;  // -> point<isq::height, si::metre, mean_sea_level>

---

Here are two examples of how a quantity will look with the above. Note how current quantity<reference<QS, U>, Rep> is replaced with quantity<delta<QS, U>, Rep>:

quantity<isq::height[m]> q1;                            // -> quantity<delta<isq::height, si::metre>, double>
quantity<point<isq::height[m], mean_sea_level>> q2;     // -> quantity<point<isq::height, si::metre, mean_sea_level>, double>

Delta quantities

We've always had the rule that Number * Reference -> Quantity. So everything that satisfies Reference above and represents a delta can be put to the right of op*.

quantity q1 = 40 * m;
quantity q2 = 40 * delta<m>;               // does it read OK?
quantity q3 = 40 * isq::height[m];
quantity q4 = 40 * delta<isq::height[m]>;  // does it read OK?
quantity q5 = 40 * delta<isq::height>[m];  // does it read OK?

We also always had explicit conversions with QuantitySpec(Quantity).

quantity q6 = isq::height(40 * m);         // converts to a strongly-typed quantity
quantity q7 = delta<isq::height>(40 * m);

Finally, to solve the "temperature problem", we have added point and delta helpers. Now, they might not be needed but still might be useful for points with an explicit origin. Please let me know if you feel that we should remove the below syntax.

quantity q8 = delta<m>(40);
quantity q9 = delta<isq::height[m]>(40);
quantity q10 = delta<isq::height>[m](40);

Point quantities

Previously, we were not allowed to use op* to create points. Now we can have such support if we decide that is a good idea. For sure, this simplifies the design and follows the Number * Reference -> Quantity rule (and now point is a `quantity). However it just looks wrong. What does it mean to have 40 points of metre?

Implicit origins

// quantity qp1 = 40 * point<m>;              // Compile-time error
quantity qp2 = point<m>(40);

// quantity qp3 = 40 * point<isq::height[m]>; // Compile-time error
// quantity qp4 = 40 * point<isq::height>[m]; // Compile-time error
quantity qp5 = point<isq::height>(40 * m);    // converts a delta to a point
quantity qp6 = point<isq::height[m]>(40);     // currently used helper
quantity qp7 = point<isq::height>[m](40);     // currently used helper

Explicit origin provided via addition

quantity qp1 = mean_sea_level + 40 * m;
quantity qp2 = mean_sea_level + 40 * delta<m>;
quantity qp3 = mean_sea_level + delta<m>(40); // currently used helper

quantity qp4 = mean_sea_level + 40 * isq::height[m];
quantity qp5 = mean_sea_level + 40 * delta<isq::height[m]>;
quantity qp6 = mean_sea_level + isq::height(40 * m);
quantity qp7 = mean_sea_level + delta<isq::height>(40 * m);
quantity qp8 = mean_sea_level + delta<isq::height[m]>(40); // currently used helper

Explicit origin provided via point<>

// quantity qp1 = 40 * point<m, mean_sea_level>;               // Compile-time error
quantity qp2 = point<m, mean_sea_level>(40);                   // currently used helper does not take origin

// quantity qp3 = 40 * point<isq::height[m], mean_sea_level>;  // Compile-time error
quantity qp4 = point<isq::height[m], mean_sea_level>(40);      // currently used helper does not take origin

[mpusz]

Explicit origin provided via quantity::relative_to()

Right now, we have the following helpers in quantity point:

qp.quantity_from_zero()  -> quantity
qp.quantity_from(Origin) -> quantity
qp.point_for(Origin) -> quantity_point

with the above changes, those probably should be renamed to:

q.delta_from_zero()  -> quantity<delta...>
q.delta_from(Origin) -> quantity<delta...>
q.point_for(Origin) -> quantity<point...>

We could consider adding a symmetric interface to obtain a point from the quantity. For example:

quantity qp1 = (40 * m).relative_to(mean_sea_level);
quantity qp2 = (40 * delta<m>).relative_to(mean_sea_level);
quantity qp3 = delta<m>(40).relative_to(mean_sea_level);

quantity qp4 = (40 * isq::height[m]).relative_to(mean_sea_level);
quantity qp5 = (40 * delta<isq::height[m]>).relative_to(mean_sea_level);
quantity qp6 = isq::height(40 * m).relative_to(mean_sea_level);
quantity qp7 = delta<isq::height>(40 * m).relative_to(mean_sea_level);
quantity qp8 = delta<isq::height[m]>(40).relative_to(mean_sea_level);

I have also considered the following names:

q.point_from(Origin)
q.point_for(Origin)

I really do not know which one is better. Let's try to use actual variable names:

height.relative_to(mean_sea_level)
height.point_relative_to(mean_sea_level)
height.point_from(mean_sea_level)
height.point_for(mean_sea_level)

Do you think we should add such a function? If so, how to name it?

[nebkat]

quantity<point>
qp.point_from(Origin) sounds more intuitive to me than qp.point_for(Origin), as a measurement could be referred to as being taken from (or with) a particular origin point, not for an origin.

player_vehicle_coordinates.point_from(global_origin)
body_temperature.point_from(absolute_zero);

Makes it consistent with delta_from too.

quantity<delta>
point_relative_to/relative_to is a bit too similar to delta_to.
point_for remains confusing as above.

point_from would be consistent with the above, though the following does seem slightly off:

(40 * isq::height[m]).point_from(mean_sea_level); 
(ground_level + 40 * isq::height[m]).point_from(mean_sea_level);
// Slightly different effect whether you start from a quantity<delta> or quantity<point>

This one is harder because these would typically be referred to as "40 meters above MSL", "10 degrees above freezing", etc.

[mpusz]

Offset units

For offset units, we decided to be specific and prevent any ambiguity. This is why the below commented-out lines should not compile:

// delta
// quantity t1 = 40 * deg_C;
quantity t2 = 40 * delta<deg_C>;
quantity t3 = delta<deg_C>(40);

// quantity t4 = 40 * isq::Celsius_temperature[deg_C];
quantity t5 = 40 * delta<isq::Celsius_temperature[deg_C]>;
quantity t6 = 40 * delta<isq::Celsius_temperature>[deg_C];
// quantity t7 = isq::Celsius_temperature(40 * deg_C);
quantity t8 = delta<isq::Celsius_temperature>(40 * deg_C);
quantity t9 = delta<isq::Celsius_temperature[deg_C]>(40);
quantity t10 = delta<isq::Celsius_temperature>[deg_C](40);

// implicit origin
quantity tp1 = 40 * point<deg_C>;
quantity tp2 = point<deg_C>(40);

quantity tp3 = 40 * point<isq::Celsius_temperature[deg_C]>;
quantity tp4 = 40 * point<isq::Celsius_temperature>[deg_C];
quantity tp5 = point<isq::Celsius_temperature>(40 * deg_C);
quantity tp6 = point<isq::Celsius_temperature[deg_C]>(40);
quantity tp7 = point<isq::Celsius_temperature>[deg_C](40);

// explicit origin provided via addition
// quantity c1 = ice_point + 40 * deg_C;
quantity c2 = ice_point + 40 * delta<deg_C>;
quantity c3 = ice_point + delta<deg_C>(40);

// quantity c4 = ice_point + 40 * isq::Celsius_temperature[deg_C];
quantity c5 = ice_point + 40 * delta<isq::Celsius_temperature[deg_C]>;
// quantity c6 = ice_point + isq::Celsius_temperature(40 * deg_C);
quantity c7 = ice_point + delta<isq::Celsius_temperature>(40 * deg_C);
quantity c8 = ice_point + delta<isq::Celsius_temperature[deg_C]>(40);

// explicit origin provided via quantity::relative_to()
// quantity qp1 = (40 * deg_C).relative_to(ice_point);
quantity qp2 = (40 * delta<deg_C>).relative_to(ice_point);
quantity qp3 = delta<deg_C>(40).relative_to(ice_point);

// quantity qp4 = (40 * isq::Celsius_temperature[deg_C]).relative_to(ice_point);
quantity qp5 = (40 * delta<isq::Celsius_temperature[deg_C]>).relative_to(ice_point);
// quantity qp6 = isq::Celsius_temperature(40 * deg_C).relative_to(ice_point);
quantity qp7 = delta<isq::Celsius_temperature>(40 * deg_C).relative_to(ice_point);
quantity qp8 = delta<isq::Celsius_temperature[deg_C]>(40).relative_to(ice_point);

// explicit origin provided via point<>
quantity qp1 = 40 * point<deg_C, ice_point>;
quantity qp2 = point<deg_C, ice_point>(40);

quantity qp3 = 40 * point<isq::Celsius_temperature[deg_C], ice_point>;
quantity qp4 = 40 * point<isq::Celsius_temperature, ice_point>[deg_C];
quantity qp5 = point<isq::Celsius_temperature, ice_point>(40 * deg_C);
quantity qp6 = point<isq::Celsius_temperature[deg_C], ice_point>(40);

[mpusz]

In the first post, I suggested removing additional delta<...> wrappers. For example, delta<isq::height> is the same as isq::height, so I proposed simplifying the former to isq::height. However, in the case of offset units, we may want to be explicit. So the question is, when should we remove delta<>?

• always
• never
• for non-offset units only (i.e., delta<deg_C> should be preserved)

[nebkat]

for non-offset units only (i.e., delta<deg_C> should be preserved)

Gets my vote.

[nebkat]

Moving the origin to the reference would be a huge improvement for my application because we use explicit representation types in most quantities which forces us to provide an origin (due to the template parameter order) - even though it is almost always default/zero. This makes the type definitions prohibitively complicated to the point that we almost always use normal quantities, which is a real shame (QP + QP protection is very desirable).

---

What does it mean to have 40 points of metre?

// quantity qp1 = 40 * point<m>;              // Compile-time error
quantity qp2 = point<m>(40);

Agreed. You can have a "point of 40 metres" but not vice-versa, and this is consistent with the idea that you cant multiply a point by a scalar.

---

Not necessarily related to this proposal, but:

The other issue I find with QPs is the restrictive nature of absolute point origins. In our application we have a GNSS library and a CANBUS library that both independently define latitudes/longitudes, without any knowledge of each other.

I would like to do the correct thing and have:

inline constexpr struct equator final : mp_units::absolute_point_origin<mp_units::isq::angular_measure> {} equator;
inline constexpr struct prime_meridian final : mp_units::absolute_point_origin<mp_units::isq::angular_measure> {} prime_meridian;

using latitude = mp_units::quantity_point<mp_units::si::degree, equator, double>;
using longitude = mp_units::quantity_point<mp_units::si::degree, prime_meridian, double>;

But now it becomes a lot more difficult to share these quantities. Converting between a gnss::latitude and a canbus::latitude would involve a bunch of gymnastics which would discourage me from using them in the first place. I understand of course that this is by design, but I believe this is something the library should address.

Said another way, in the library, there is no way to spell how two distinct absolute_point_origin types relate to each other.

If there was a way to define e.g. mp::equivalent_point_origin<gnss::latitude, canbus::latitude> - with the express purpose of bridging identical origins - that would make it much more usable. It doesn't help if one library doesn't use absolute origins or points at all, but this might just be the catalyst needed to ensure that it does.

[mpusz]

I am probably not best placed to suggest a full solution for the domain...

That is OK. Let's start with something and let's see where it leads us. Maybe others will start to contribute as well?

Preventing an accidental conversion from a WGS84 latitude to a GRS80 latitude would be a great application of quantity safety

Sure, I totally agree. A potential design question here is if we should have different origins for different systems or maybe each system should be a leaf in a latitude/longitude hierarchy tree? Something like:

flowchart TD
    isq::angular_measure --> latitude
    latitude --> itrf2014::latitude
    latitude --> itrf2020::latitude

Loading

The above with #668 (comment) could give the safety you need, right?

I think it would be good to further distinguish between the concepts of a quantity point and a quantity point with an explicit origin.

I think it is an interesting idea but I am not sure if I fully follow your thoughts here. How would we specify that wgs84::prime_meridian is an implicit point origin but new_york is not? Is new_york a relative_point_origin? Even if it is, points defined in terms of relative origins are always convertible to other points assuming that the absolute origin is the same.

---

Please note that I am on my vacation in Italy now after a really hard 6 weeks of work on non mp-units-related subjects. I should be back by the end of the weak and after Easters I plan to work hard on mp-units again.

[nebkat]

Hope you're enjoying the vacation, no rush getting back to me!

Sure, I totally agree. A potential design question here is if we should have different origins for different systems or maybe each system should be a leaf in a latitude/longitude hierarchy tree? Something like:

This would technically achieve the desired behavior, but I don't think it would be correct conceptually. A latitude is a latitude regardless of which origin point is used. An ITRF2020 latitude isn't a different kind of quantity to an ITRF2014 latitude, it's just using a slightly different ellipsoid model.

I suspect in some other domain there could be an example where there are also many different origin points, but you still might want a further degree of specificity in the quantity kind such as isq::radius vs isq::length.

---

I think it is an interesting idea but I am not sure if I fully follow your thoughts here. How would we specify that wgs84::prime_meridian is an implicit point origin but new_york is not? Is new_york a relative_point_origin? Even if it is, points defined in terms of relative origins are always convertible to other points assuming that the absolute origin is the same.

It could either be a non-implicit absolute origin, or a relative origin to some other absolute origin, depending on what we mean by new_york - though I would still prevent implicit conversions to an originless point for both. To better illustrate:

We may want a variable that very loosely defines how many degrees north or south we are from New York, without suggesting that we can convert this back to a real latitude, e.g.:

inline constexpr struct new_york final : absolute_point_origin<latitude> {} new_york; // Where is this? Somewhere, who knows! 
auto london = point<latitude[si::degree], new_york>(11); // London is roughly 11° north of New York
quantity<point<latitude[si::degree]>> a = london; // ❌ This measurement is meaningless without the context of new_york
quantity<delta<latitude[si::degree]>> b = london - new_york; // ✅ There is logic to this

OR we may want to say no - New York is located at a exactly 40.7128°N of the equator under ITRF2020 - it's a real place.

namespace itrf2020 {
inline constexpr struct equator final : implicit_point_origin<latitude> {} equator;
}

inline constexpr struct new_york final : relative_point_origin<point<latitude[si::degree], itrf2020::equator>(40.7128)> new_york {};
auto london = point<latitude[si::degree], new_york>(10.7944); // London is exactly 10.7944° north of New York
quantity<point<latitude[si::degree]>> a = london; // ❌ This is still risky, did the user want to get back a point of 10.7944° or 51.5072°?
quantity<point<latitude[si::degree], itrf2020::equator>> b = london; // ✅ We are on the same origin line and the intention is clear
quantity<point<latitude[si::degree]>> c = b; // ✅ Now this is OK - itrf2020::equator is implicitly zero so it's not crazy to think we would want an originless point from it
quantity<point<latitude[si::degree]>> d = london.point_from_implicit_zero(); // ✅ Explicitly saying we're willing to lose the specificity of itrf2020 - in one operation
// Which is much like quantity_from_zero(), except we keep point semantics

I think this follows how we normally speak about such quantities. If I was told Paris is located at "48.8575°N of the ITRF2020 equator", it wouldn't be a crime to pass that information on as "48.8575°N". If someone did care about the datum, they would say "can you give me that coordinate in ITRF2020", and I would verify this before giving it back to them (mp::origin_cast).

On the other hand if I was told London is located 11 degrees north of New York, there isn't a lot I could do with that information except repeat it back verbatim (absolute case). If I was also told New York is at exactly 40.7128°N itself (relative case) then I could start to reason about an absolute location for London - but it would strictly involve an addition operation first (qp.point_from(...)).

---

The voltage example also illustrates this well.

Every voltage reading needs to have a reference/origin. Usually it is local ground, but it could be local earth, shield, or a completely different voltage rail such a USB VBUS or even just +12V (i.e. what is our voltage above the 12V rail). These are all very clearly their own absolute origins, because they can change relative to each other over time - but again some of them are more implicitly zero than others:

4V above ground => a voltage of 4V ✅
4V above earth => a voltage of 4V ✅
4V above shield => a voltage of 4V ✅
4V above 12V => a voltage of 4V ❌ we can't just throw away the context like that, and we can't even convert it to a ground voltage because sometimes the 12V rail might spike to 12.5V above ground!

So what we have is:

inline constexpr struct ground final : implicit_point_origin<isq::voltage> {} ground;
inline constexpr struct earth final : implicit_point_origin<isq::voltage> {} earth;
inline constexpr struct shield final : implicit_point_origin<isq::voltage> {} shield;

inline constexpr struct rail_12v final : absolute_point_origin<isq::voltage> {} rail_12v; // voltage _relative_ to 12V rail
inline constexpr struct usb_vbus final : absolute_point_origin<isq::voltage> {} usb_vbus; // voltage _relative_ to USB VBUS

auto a = point<isq::voltage[si::volt], ground>(4);
auto b = point<isq::voltage[si::volt], earth>(5);

quantity<point<isq::voltage[si::volt]>> c;

c = a; // ✅ Implicitly a "voltage of 4V"
c = b; // ✅ Implicitly a "voltage of 5V"

Now we might say this is scary - we're mixing different quantities - isn't the library meant to prevent that? But we made it clear we didn't care when we defined the type of c without an origin.

If a function did care it would make it explicit in it's parameter:

void calculate_xyz(quantity<point<isq::voltage[si::volt], ground>> qp);
calculate_xyz(c); // ❌ Gotta make sure we're passing in a ground voltage!
calculate_xyz(mp::origin_cast<ground>(c)); // ✅ I promise this quantity is in fact relative to ground

---

Remaining questions under this system:

• This doesn't necessarily address the original problem of nmea::latitude vs geojson::latitude, though it would be a step in the right direction
• Naming: implicit_point_origin vs absolute_point_origin isn't great
• Would zeroth_point_origin still exist? Or would you always have to firstly define an absolute_point_origin or implicit_point_origin before making a relative_point_origin?

inline constexpr struct new_york final : relative_point_origin<point<latitude[si::degree]>(40.7128)> new_york {};
auto london = point<latitude[si::degree], new_york>(10.7944); // London is exactly 10.7944° north of New York
quantity<point<latitude[si::degree]>> a = london; // ❓This feels risky as before, but new_york is relative to this, so following our rules it should be allowed
// Prevent the definition of the relative origin in the first place?
// But then we are forcing users to define more origins they might not even care about!

Some of my origins are for encoding binary offsets rather than quantity concepts, so I would be forced to invent an implicit/absolute origin to make them work - not great:

// Latitude definition for serialization
struct df101_latitude {
    static constexpr auto unit = mp::mag<180> * mp::mag_power<2, -39> * mp::si::degree;
    static constexpr auto spec = mp::isq::angular_measure;
    static constexpr auto reference = spec[unit];
    static constexpr struct offset final : mp::relative_point_origin<mp::absolute<reference>(-std::pow(2, 39))> {} offset {};
    using rep_type = nonstd::unaligned_uint40_t;
    using quantity_point_type = mp::quantity_point<reference, offset, rep_type>;
}

But maybe this should be a concern for my representation type?

---

To summarize:

• Loosening of the rules for origins which we commonly view as natural/zero origins
• Library developers are free to be as correct as possible in their quantity definitions
• End users are not punished if they don't care about the specifics
• When the specifics are important (non-implicit origins), end user is forced to handle them appropriately
• Point semantics preserved instead of dropping to delta quantities

[mpusz]

@nebkat, thanks a lot for sharing cool ideas! 👍🏻

I think that you have some typos or errors in the second example quantity<point<latitude[si::degree], itrf2020::equator>> b = a; as a should not compile according to your comments.

I see no risk in this. A point in space is exactly the same point no matter if I measure it from the floor, wall, ceiling, or the nearest chair. If all of those origins share the same coordinate system (have the same absolute_point_origin), I can easily convert the internal representation of my point to be measured relative to any of those origins.

The rest makes a lot of sense. Now we have to make it a proper design 😉

Naming: implicit_point_origin vs absolute_point_origin isn't great

Right, we could use better names here. Maybe absolute_point_origin could be renamed to distinct_point_origin or something else?

Would zeroth_point_origin still exist

What should I get when I ask for the origin of a point with implicit_point_origin (e.g., quantity<point<latitude[si::degree]>>::point_origin)? I can't return implicit_point_origin<latitude> as it is not final. Or maybe we should drop the final requirement on origins as it is not really that needed here, but this would be inconsistent with the rest of the definitions where symbolic equations simplifications need to work correctly.

Or would you always have to firstly define an absolute_point_origin or implicit_point_origin before making a relative_point_origin?

Is it safe to define a relative_point_origin in terms of implicit_point_origin? implicit_point_origin requires origin_cast, but the relative one does not need one.

Some of my origins are for encoding binary offsets rather than quantity concepts, so I would be forced to invent an implicit/absolute origin to make them work - not great:

Yes, this seems similar to our hw_voltage example. I do not think the representation type should cover it, and a custom point origin appears to be the correct use case here.

[nebkat]

I think that you have some typos or errors in the second example quantity<point<latitude[si::degree], itrf2020::equator>> b = a; as a should not compile according to your comments.

Correct, that is now fixed to quantity<point<latitude[si::degree], itrf2020::equator>> b = london;

Right, we could use better names here. Maybe absolute_point_origin could be renamed to distinct_point_origin or something else?

I like that, or maybe one of its synonyms:

distinct_point_origin
detached_point_origin
unique_point_origin
disjointed_point_origin

A distinct/detached/unique/disjoint scale from all other scales. It would take over the current behavior of an absolute_point_origin.

Then what I have thus far called an implicit_point_origin could be:

normal_point_origin
standard_point_origin
natural_point_origin
canonical_point_origin
zero_point_origin (with existing removed)
absolute_point_origin (as opposed to relative, but it doesn't fully symbolize its "normal" / "implicit zero" nature)

When choosing which to use for a particular origin, the deciding factor would be "does this point still make sense in its quantity spec if the origin was removed/truncated?".

If yes => normal_point_origin
If no => distinct_point_origin

namespace itrf2020 {
inline constexpr struct equator final : normal_point_origin<itrs::latitude> equator {}; // Latitude without explicit equator makes sense
inline constexpr struct geoid final : normal_point_origin<itrs::geoid_undulation> geoid {}; // Geoid undulation without explicit geoid is still meaningful
}

namespace hw_voltage {
inline constexpr struct ground final : normal_point_origin<isq::voltage> ground {};
inline constexpr struct earth final : normal_point_origin<isq::voltage> earth {};
inline constexpr struct shield final : normal_point_origin<isq::voltage> shield {};

inline constexpr struct vbus final : distinct_point_origin<isq::voltage> vbus {};

inline constexpr struct neutral final : normal_point_origin<isq::current> neutral {};
inline constexpr struct phase final : distinct_point_origin<isq::current> phase {};
}

namespace game::coordinate {
inline constexpr struct world final : normal_point_origin<isq::position_vector> world {};
inline constexpr struct player final : distinct_point_origin<isq::position_vector> player {};
inline constexpr struct vehicle final : distinct_point_origin<isq::position_vector> vehicle {};
inline constexpr struct camera final : distinct_point_origin<isq::position_vector> camera {};
}

namespace thermal {
inline constexpr struct ambient final : distinct_point_origin<isq::temperature> ambient {};
}

namespace navigation {
inline constexpr struct true_north final : normal_point_origin<isq::angular_measure> true_north {};
inline constexpr struct magnetic_north final : distinct_point_origin<isq::angular_measure> magnetic_north {};
}

What should I get when I ask for the origin of a point with implicit_point_origin (e.g., quantity<point<latitude[si::degree]>>::point_origin)? I can't return implicit_point_origin as it is not final. Or maybe we should drop the final requirement on origins as it is not really that needed here, but this would be inconsistent with the rest of the definitions where symbolic equations simplifications need to work correctly.

Could it be a fixed undefined_point_origin, or have qp::point_origin not defined at all with a template specialization? We do need the default origin behavior for degree Celsius, but 99% of quantities/units don't have an equivalent.

A relative_point_origin<point<..., undefined_point_origin>(10)> is perhaps a little strange, but not unthinkable. It would be perfect for binary offsets where there is no need for a named origin.

Is it safe to define a relative_point_origin in terms of implicit_point_origin? implicit_point_origin requires origin_cast, but the relative one does not need one.

We might be getting confused around the terms here - I think yes that would be ok.

The primary purpose of origin_cast would be to promote from an undefined_point_origin QP / point<isq::voltage> to a normal_point_origin QP / point<isq::voltage, ground> (or a QP with a relative_point_origin derived from a normal_point_origin).

flowchart TD
    ground_plus_2["point&lt;..., ground_plus_2&gt;"] <-- implicit --> ground["point&lt;..., ground&gt;"]
    ground <-. "origin_cast&lt;...&gt;" .-> earth["point&lt;..., earth&gt;"]
    ground -- implicit --> undef["point&lt;...&gt;"]
    undef == origin_cast&lt;ground&gt; ==> ground & ground_plus_2
    undef -. origin_cast&lt;ground_plus_2&gt; .-> ground_plus_2
    earth -- implicit --> undef
    undef == origin_cast&lt;earth&gt; ==> earth
    ground_plus_2 -- implicit --> undef
    linkStyle 1 stroke:#FF6D00
    linkStyle 5 stroke:#FF6D00

Loading

• Allow origin_cast between two normal_point_origins?
  • Between latitudes of different datums generally seems reasonable
  • Between ground/earth/shield seems reasonable
  • If something bad was to happen, the origin probably should've been distinct in the first place?
  • It would largely solve the multiple library problem
• Allow origin_cast<relative_point_origin<normal_point_origin<...>>> as opposed to insisting on origin_cast<normal_point_origin> and having the implicit conversion do the rest?
  • Don't want give the impression that origin_cast is just setting point_origin = X?
  • Well, it is, but only because X is a normal_point_origin - it's not a sudo_cast
• I was concerned about implicit demotion from relative origin to no origin but you are right, if it is on a normal scale its value is unambiguous so its not a problem

flowchart LR
 subgraph s1["Distinct scale"]
   direction LR
        earth["point<..., usb_vbus>"]
        n1["point<..., usb_vbus_plus_2>"]
  end
    ground["point<..., ground>"] x--x earth
    earth x--x undef["point<...>"]
    earth <-- implicit --> n1
    n1 ~~~ undef & ground
    linkStyle 0 stroke:#D50000,fill:none
    linkStyle 1 stroke:#D50000,fill:none

Loading

Of course once we are in distinct land the only way we can get back is through deltas and manual conversion functions.

---

Alternatively, something closer to implicit/explicit/quantity_cast:

flowchart TD
 subgraph s1["Distinct scale"]
    direction LR
        n1["point<..., usb_vbus_plus_2>"]
        n2["point<..., usb_vbus>"]
  end
    ground_plus_2["point&lt;..., ground_plus_2&gt;"] <-- implicit --> ground["point&lt;..., ground&gt;"]
    ground <== "origin_cast&lt;...&gt;" ==> earth["point&lt;..., earth&gt;"]
    ground -- implicit --> undef["point&lt;...&gt;"]
    undef == explicit ==> ground & ground_plus_2 & earth
    earth -- implicit --> undef
    ground_plus_2 -- implicit --> undef
    n1 <-- implicit --> n2
    undef x--x s1
    linkStyle 9 stroke:#D50000

Loading

[mpusz]

Thanks! That explains a lot. I also love your diagrams ❤️