quantity vs quantity_point - did we get the defaults wrong?

[mpusz]

The more I think about it, the more I am getting convinced that we might have got the defaults wrong. It seems to be a common issue in the C++ language ;-)

People who are not experts in the domain typically think about (and use) quantity points only when talking about temperatures. If they know std::chrono, they might also be tempted to use them for time points. That's it. Most users will not use points for anything else.

However, it seems that most of the things we want to model are points. The speed of a car, the altitude of a point, some position distant from home, latitude and longitude, heading, energy state, and many more are actually points. If we think about this as being our default, suddenly, the entire discussion we have about the non-negative quantities in #468 starts to make sense. Immediately, a radius can't be negative. Likewise, the speed of a car defined by ISO as a magnitude of the velocity (so implicitly non-negative), also seems to be non-controversial.

Our quantity type, being the workhorse of the library, is a relative type, though. We should talk about relative types only when we talk about the difference between two points, so a delta of some quantity. It seems that such use cases are actually less common. Let's think about the interfaces we wrote in the last years for our libraries:

• when we define a box, we talk about length dimensions being points,
• when we get a speed (i.e. speed limit), we typically mean a point too,
• the same applies to energy.

However, people tend to use quantity for those in the majority of cases. Even we, who are the experts in the domain, do the same. There might be a few reasons for it:

1. It works! quantity provides all operations of quantity_point and more. People often do not think if adding two quantity values for abstractions they want to model makes sense or not. Often, it does not, which is a clear highlight that a point should be used instead. But as it compiles fine, a quantity type is wrongly used in such cases. Even our avg_speed example that we use in every documentation or slides returns a relative type instead of the point.
2. We are lazy! quantity_point is more to type than quantity. There are also more template parameters if we want to provide them explicitly. Also, currently, the quantity_point construction is harder and more verbose as it always requires the addition/subtraction of PointOrigin and a quantity.
3. Other libraries do the same or do not provide a point abstraction at all. Such users just copy the habits from the library that they used before to mp-units.

Maybe we should change the defaults? Maybe a quantity should mean a point, and maybe we should rename the current type to something like delta_quantity? If the user would have to type more for those, automatically, a point would become the default. We could consider various names for the differential type:

• delta_quantity
• relative_quantity
• diff_quantity
• vector_quantity (this name might collide with vector and tensor quantities in the ISO meaning).

With such naming conventions for those two abstractions, people would often initially use points by default and switch to relative types in case of a compilation error (clearly highlighting that a point is not a good abstraction there).

Maybe we should also simplify the usage of points in the library to encourage their wider usage? The biggest issue I see is that, right now, we require a strong type for point origin to be explicitly defined and used when we just want to express the point relative to zero. In the currency example, at some point, I already ended up with something like:

inline constexpr struct no_money : absolute_point_origin<currency> {} no_money;

quantity_point qp = no_money + 42 * euro;

That is quite inconvenient, to say the least. It is even worse when we do not want to, or simply can't, use CTAD. For example:

inline constexpr struct no_money : absolute_point_origin<currency> {} no_money;

struct data {
  quantity_point<currency[euro], no_money, int> price = no_money + 0 * euro;
};

For most of the quantities, there is no need to redefine a point that just means zero all over again. To simplify the usage of such points, maybe we should provide an implicit zero point origin in the library?

template<QuantitySpec auto QS>
struct zero_ : absolute_point_origin<QS> {};

template<QuantitySpec auto QS>
inline constexpr zero_<QS> zero;

Maybe we should also restore the implicit point origin when the user does not provide one?

template<Reference auto R,
                 PointOriginfor<get_quantity_spec(R)> auto PO = zero<get_quantity_spec(R)>, 
                 RepresentationOf<get_quantity_spec(R).character> Rep = double>
class quantity_point;

With the above, we could type:

quantity_point qp1 = zero<currency> + 42 * euro;                  // quantity_point<euro>, zero<currency>, int>
quantity_point<currency[euro]> qp2 = zero<currency> + 42 * euro;  // quantity_point<currency[euro], zero<currency>, int>

Maybe we should again allow the construction of a point just from the relative quantity without the need to explicitly mention the origin?

quantity_point qp1 = 42 * euro;                 // quantity_point<euro, zero<kind_of<currency>>, int>
quantity_point<currency[euro]> qp2 = 42 * euro; // quantity_point<currency[euro], zero<currency>, int>

However, please note that even with the above, the multiply syntax still means the relative type:

auto q = 42 * euro;  // quantity<euro, int>

The above changes will simplify the usage of most of the points a lot. However, it will break the current verbose but always correct usage of temperatures in units other than kelvins. From the below examples only t2 and t4 will construct what most users expect:

quantity_point t1 = 20 * deg_C;
quantity_point t2 = si::zero_Celsius + 20 * deg_C;
quantity_point<isq::Celsius_temperature> t3 = 20 * deg_C;
quantity_point<isq::Celsius_temperature, si::zero_Celsius> t4 = 20 * deg_C;

This is really unfortunate :-( I also think that the current approach of requiring the user to always provide si::zero_Celsius (often even twice) is a bit unfortunate as well:

quantity_point<si:degree_Celsius, si::zero_Celsius> t = si::zero_Celsius + 20 * deg_C;

Also, many users will probably find it hard to define their own first point as they may not be aware of si::zero_Celsius (or usc::zero_Fahrenheit) existence.

This is why maybe we should rediscuss providing a default point origin in a unit definition?

inline constexpr struct degree_Celsius : named_unit<basic_symbol_text{"°C", "`C"}, kelvin, zero_Celsius> {} degree_Celsius;

With such support, we could redefine the quantity_point to first check for a point origin in a unit definition and only otherwise, use the zero point origin:

template<Reference auto R,
                 PointOriginfor<get_quantity_spec(R)> auto PO = unit_point_origin_or(get_unit(R), zero<get_quantity_spec(R)>),
                 RepresentationOf<get_quantity_spec(R).character> Rep = double>
class quantity_point;

With the above, all the t1 - t4 cases provided before would yield the expected type and value.

One more point to consider here is if a construction of a point from a difference type should be allowed to happen implicitly or should it be explicit only.

To summarize, I have a strong feeling that the changes described above would not only greatly simplify the current usage of points for temperatures but would also encourage users to use points more often for other quantity types, which would improve their designs and safety.

---

With all of the above changes, our hello units example could be changed to:

QuantityOf<isq::speed> avg_speed(DeltaQuantityOf<isq::length> dl, DeltaQuantityOf<isq::time> dt)
{
  return quantity{dl / dt};
}

quantity home_odometer = isq::distance(320 * km);
quantity destination_odometer = isq::distance(540 * km);
delta_quantity distance = destination_odometer - home_odometer;
delta_quantity duration = 2 * h; // measured twice with std::chrono::system_clock::now() and subtracted
quantity speed = avg_speed(distance, duration);
std::println("A car that drove the distance of {} in {} had an average speed of {}",
             distance, duration, speed.delta_from(zero<isq::speed>));

The above changes might look a bit drastic at first, but please notice how they:

• simplify the code using points (try to implement this with the current version of the library),
• allow us to benefit from non-negative quantities,
• enforce good safer design.

I am not claiming that we should apply all of those changes. Please treat the above proposals with some grain of salt. Some of them are intentionally a bit controversial to force us to move a bit from the paved paths and explore new possibilities with an open mind. Maybe some of them are reasonable and should be implemented though?

Please do share your thoughts, questions, preferences, and suggestions.

[JohelEGP]

This is an interesting discussion.

---

when we get a speed (i.e. speed limit), we typically mean a point too,

I have thought about the general issue in the past, but not to the extent in this discussion.
With speed, zero can be interpreted as "not moving".
Similar things happens with other quantities,
so my conclusion was that using points would be an overkill.

---

Even our avg_speed example that we use in every documentation or slides returns a relative type instead of the point.

To compute averages, you need addition.
If you have a list of speed points (e.g., positions of the arrow in a speed-o-meter),
you wouldn't think it twice about adding them.
In code, if you have a point, you'd have to use .relative() (if that's still its name).
That'd be considered a safety feature,
but are speeds really generally points?

This is similar:

inline constexpr struct no_money : absolute_point_origin<currency> {} no_money;

It makes me think "duh", which isn't good.

si::zero_Celsius

Shouldn't this be zeroth_Celsius?
It's an ordinal, after all.

quantity home_odometer = isq::distance(320 * km);

The ISO 80000 definition of distance screams relative.

distance | shortest path length (item 3‑1.7) between two points in a metric space

---

However, it seems that most of the things we want to model are points. The speed of a car, the altitude of a point, some position distant from home, latitude and longitude, heading, energy state, and many more are actually points.

The ISO 80000 definition of altitude definitely suggests a point.
But as has been demonstrated, there are cases for relative heights.
If 3 * m defaults to a point from "zero",
and sea_level + 3 * m is 3 m above the sea level,
just how verbose will it be to express just "3 meters"?

height, depth, altitude | minimum length of a straight line segment between a point and a reference line or reference surface

What if you could write something like 3nth * m instead?

---

when we define a box, we talk about length dimensions being points,

What lengths, though?
A box definitely has dimensions, which are relative.
If the box is in a space, it also has a position.
Those are two different abstractions.
The "box in a space" builds on top of the "box in the abstract".

---

Maybe we should change the defaults? Maybe a quantity should mean a point, and maybe we should rename the current type to something like delta_quantity?

I think it was in #93 where I suggested different names that don't favor any.
More recently, I've suggested just vector and point.
And for vector, relying on layers of abstraction to not collide with its other meanings.
Just like the "quantity" concept exploits the language context (e.g., length quantity, the quantity 3 s).

[JohelEGP]

People often do not think if adding two quantity values for abstractions they want to model makes sense or not. Often, it does not, which is a clear highlight that a point should be used instead.

This is why I like vector and point.
They are succinct and to the point.
One just needs to learn that "vector" (as in the element of a vector space) is a generalization of scalars
(which are vectors in the number line or complex field).
Then an interface like void f(vector<length[m]>); will more easily scream at you if it should have been point.

[mpusz]

To compute averages, you need addition.

Sure, but our avg_speed example is not about averaging some speed values but about obtaining an average driving speed in a duration of, let's say, 2 hours.

In code, if you have a point, you'd have to use .relative() (if that's still its name).

Now it's much longer, as it started to be origin-safe. We have to call .quantity_from(zero<isq::speed>)

That'd be considered a safety feature,

I am not sure how this might be a safety issue?

[mpusz]

The ISO 80000 definition of distance screams relative.

Right, maybe I should use a different quantity type for it.

[mpusz]

If 3 * m defaults to a point from "zero",

As I stated in my initial post, 3 * m defaults to a vector. But we could make the following legal:

quantity_point qp = 3 * m;

which would easily create a point from zero<kind_of<length>> without the need to explicitly define such a point first and then use it during the construction.

[chiphogg]

If we do this, I expect it moves standardization to C++32, minimum: it's such a drastic change that we'll be starting from scratch on implementation experience. What's more, I think there's an ~80% chance that what we'd be standardizing in C++32 would be very similar to what we have today: I don't think this change is an improvement, and I expect the extra time would go into discovering precisely why.

It's not at all clear to me that a speed is well modeled by a quantity point. I definitely see the motivation --- in fact, I've explored similar ideas myself! But quantity points don't support multiplication, so we would be destroying the ability to multiply a speed by a time and get a displacement. And ultimately, that's what a speed is --- a ratio of two quantities, one of distance and one of time.

Big picture: I think what we are bringing to the committee is already very good! There will always be the temptation to polish and refine; it will never feel "done". But we need to be especially wary of making changes that unduly increase friction for more casual users, changes that raise the barrier for entry. mp-units has done a great job making its more sophisticated features, like quantity kinds, get out of the way for people who don't care to use them. Let's stick with this approach so that we end up with a library that far more people will actually use.

And if it does turn out that points are "better", but we stick with the status quo? The "failure mode" is that we have taken probably the best software units library yet written (every library is quantity-default!) and provided it to the entire C++ community. I can live with that.

[mpusz]

One question I have regarding the default origins is how the following code should work:

quantity_point qp = 42 * deg_C / s;

I assume that zero<QuantitySpec> should be used and that we should ignore the default origin of deg_C as in order to create a derived quantity we have to multiply/divide quantities and not points and those do not have origins.

[JohelEGP]

Isn't 42 * deg_C a vector quantity?

[mpusz]

Yes, it is, but then we convert the quantity being the result of 42 * deg_C / s to quantity_point and it will look for a unit-provided origin. There is none provided for deg_C / s unit but maybe it should also analyze the definitions of ingredients? I do not think it should, but I am asking just to ensure that is correct.

[JohelEGP]

So with

I assume that zero<QuantitySpec> should be used

you mean zero<decltype(42 * deg_C / s)::quantity_spec>, right?
I don't see deg_C having an associated origin in the code.
Are you also going to add that?

[mpusz]

you mean zero<decltype(42 * deg_C / s)::quantity_spec>, right?

Yes, this is what I mean.

I don't see deg_C having an associated origin in the code.
Are you also going to add that?

I have not started any implementation from this discussion so far, as I am awaiting your feedback first. I will probably do that when I am back from my Hawaii vacation that I start on Saturday.

[mpusz]

Please let me know if you would like to see any of the changes described above being implemented.

[JohelEGP]

I think Celsius and Kelvin temperatures have an obvious zeroth point.
So point creation would benefit from not having to be explicit.

I think the "obvious zeroth point" generalizes.
Sometimes you have abstractions that are points,
but whose origin isn't of interest (and is actually the same as the relative zero).
In those cases, the only important part is that you are working with points
(e.g., adding their values doesn't make sense).
You bring the example of speed limits.
Those are generally points, rather than a difference (e.g., a change in speed limits between successive years).
Adding those speed limit points doesn't make sense,
but their zeroth point is also unimportant (and I think no different from the relative zero).

So yeah, I agree there's value with implicit zeroth points.
Although it doesn't bring the safety of explicit zeroth points (which we don't need in many cases!),
it brings the important safety of stating that we're working with points.

[mpusz]

By "So point creation would benefit from not having to be explicit." do you mean both:

• having a default value for a template parameter
• being able to implicitly/explicitly create quantity_point from the quantity value without the need for addition and subtraction with the point origin

?

[JohelEGP]

Yes. Both are necessary do dismiss any explicit zeroth point in the use of points.

[mpusz]

So the question now is, should we have an explicit or implicit construction from a quantity?

[JohelEGP]

I think it's fine to have an implicit construction from a vector if the zeroth point is the implicit/default one.

[mpusz]

Finally, I had some time to work on it, and I really like the results.

The previous solution to the Forbes issue was the following:

  {
    std::cout << "Input in degree Celsius\n";

    const quantity_point max = si::ice_point + 43. * deg_C;
    const quantity_point avg = si::ice_point + 25. * deg_C;

    std::cout << "max: " << max.quantity_from(si::ice_point) << " ("
              << max.quantity_from(usc::zero_Fahrenheit).in(deg_F) << ")\n";
    std::cout << "avg: " << avg.quantity_from(si::ice_point) << " ("
              << avg.quantity_from(usc::zero_Fahrenheit).in(deg_F) << ")\n";
  }

  {
    std::cout << "\nInput in degree Fahrenheit\n";

    const quantity_point max = usc::zero_Fahrenheit + 109. * deg_F;
    const quantity_point avg = usc::zero_Fahrenheit + 77. * deg_F;

    std::cout << "max: " << max.quantity_from(usc::zero_Fahrenheit) << " ("
              << max.quantity_from(si::ice_point).in(deg_C) << ")\n";
    std::cout << "avg: " << avg.quantity_from(usc::zero_Fahrenheit) << " ("
              << avg.quantity_from(si::ice_point).in(deg_C) << ")\n";
  }

With the changes I did today on my PC, now we can write:

  {
    std::cout << "Input in degree Celsius\n";

    const quantity_point max = 43. * deg_C;
    const quantity_point avg = 25. * deg_C;

    std::cout << "max: " << max.quantity_from_zero() << " (" << max.in(deg_F).quantity_from_zero() << ")\n";
    std::cout << "avg: " << avg.quantity_from_zero() << " (" << avg.in(deg_F).quantity_from_zero() << ")\n";
  }

  {
    std::cout << "\nInput in degree Fahrenheit\n";

    const quantity_point max = 109. * deg_F;
    const quantity_point avg = 77. * deg_F;

    std::cout << "max: " << max.quantity_from_zero() << " (" << max.in(deg_C).quantity_from_zero() << ")\n";
    std::cout << "avg: " << avg.quantity_from_zero() << " (" << avg.in(deg_C).quantity_from_zero() << ")\n";
  }

How do you like the above?

in(Unit) does not automatically change the origin. Only the underlying quantity is changed to be expressed in a new unit.

.quantity_from_zero() above always returns a quantity from the unit's zero point origin, which is either provided explicitly in the units' definition or implicitly an instance of zero<QuantitySpec>. It is available only if a quantity_point is defined in terms of such an origin.

BTW, this zero point origin probably should be renamed for standardization. Would you happen to have any ideas on a better name? For example, zero_point_origin_of_unit?

[mpusz]

Plenty of examples where we use the current unit are in the math.h header https://github.com/mpusz/mp-units/blob/master/src/utility/include/mp-units/math.h.

[chiphogg]

This is just because of the integer type, right? If you replace 20 with 20., then I expect it would compile and be correct.

No, it is to limit confusion. It does not compile because both units have a different associated origin. From a definition like:

quantity_point<usc::degree_Fahrenheit> qp1{20 * deg_C};

it is not clear if the user wanted to provide a quantity_point in degree Celsius measured from zeroth degree Fahrenheit or Celsius. I could read that the intent is to create a quantity_point<usc::degree_Fahrenheit, usc::zeroth_degree_Fahrenheit> storing a value with an offset corresponding to 20 degrees Celsius.

I goofed here --- sorry. Here's what I was actually thinking, versus what I said:

// I said that this should compile:
quantity_point<usc::degree_Fahrenheit> qp1{20. * deg_C};

// What I *meant* was that *this* should compile:
quantity_point<usc::degree_Fahrenheit> qp1 = quantity_point{20. * deg_C};

The fact that the first one doesn't compile is solid --- I really like the very narrow quantity-to-point conversion path. I don't think I would have come up with it on my own, or noticed that it's mostly (or entirely?) safe.

I assume the second one would compile and work just fine, producing quantity_point{68. * deg_F}.

I think .quantity_from_zero() would be clearly wrong for these types. (If it's even allowed --- I think I read elsewhere that it wouldn't be.)

The current design allows .quantity_from_zero() only for quantity_points defined in terms of implicit point origin even if it is length or speed. If you specify an explicitly defined point origin like mean_sea_level then .quantity_from_zero() will not compile. Although, I am not sure if that is a good idea and maybe it should work as well.

I struggle to see how it could be not unit-safe in this case, though.

Importantly, if instead of printing this quantity, we passed it to another computation, then I think it would not be correct.

Why not? The value of the quantity will be exactly as printed...

"Unit-safe" means that the unit-correctness of a given line of code can be judged by inspection, in isolation. If we see .quantity_from_zero(), but the quantity point type is defined in another line, then we can't know what quantity will be returned --- it's just like calling .count() on a std::chrono::duration type.

The only way this could be unit-safe is if we correctly account for the origin in that same line.

For printing quantity points, in cases where the origin is strongly unambiguous, this is the case. So I would consider these uses of .quantity_from_zero() to be unit-safe.

It's true that "the value of the quantity will be exactly as printed". But which quantity is that? Again --- the quantity itself will change based on the choice of origin, and that choice is made in some other (possibly very remote) line of code. Does that make it clear why this is not unit-safe?

Or, to put it another, more concrete way. Can you think of a single example where passing .quantity_from_zero() to an API that takes a quantity --- and doesn't also take the origin explicitly into account --- is robustly meaningful and correct?

Plenty of examples where we use the current unit are in the math.h header https://github.com/mpusz/mp-units/blob/master/src/utility/include/mp-units/math.h.

This is great! I skimmed through all of the examples, and it seemed like 100% of them also took steps to handle the unit explicitly. This seems like (weak) confirmatory evidence of the principle, "Any code that retrieves the underlying value of a quantity (or quantity point) without naming the unit (or origin) at the callsite is wrong, unless it is paired directly with code that takes that unit (or origin) into account."

[mpusz]

OK, now I understand better your claim about the lack of unit safety. Well, actually, we should talk about origin-safety here. If I am not wrong, the only case where we may find some issues is when we redefine the entire measurement domain/scale.

Let's suppose that we have a database with ground elevation altitudes measured as a height from the mean sea level. As we were lazy we chose to use less safe but easy-to-use implicit origins. As a result, all of the constructors take the height quantity value directly without any explicit origin (e.g., mean_sea_level) provided. In fact, trying to provide such an origin in a construction will result in a compile-time error as it has nothing in common with the implicit zeroth point origin.

If we define a point origin relative to our implicit zero and redefine the quantity_point to use it, our simplified construction will again fail to compile, as the simplified syntax works only when we use the implicit zero as an origin. So we are safe again.

The only problem can happen when we redefine the entire measurement domain. For example, instead of measuring from the mean_sea_level we will start measuring altitudes from the center of the Earth. In such case, our hard coded values at construction will, of course, mean something different and will be clearly wrong. But in such a domain, we can't even define a relative point origin representing mean sea level as it turns out that the sea level will have different distances from the Earth's center in different places. Also, Mt Everest will not be the highest peak on Earth 😜

Of course, the usage of explicit point origins makes things safer but at the expense of simplicity. This is an engineering tradeoff we make here.

[mpusz]

Ahh, I finally understand your issue. It took me a while. Sorry...

So if we have quantity point in kelvins and we use this value for calculating some derived quantities in SI units and then someone changes the unit to degree Celsius, then all the values will be wrong if we use qp.quantity_from_zero(). Do I understand it correctly? Do you suggest providing qp.quantity_from_zero_in(Unit) instead?

[chiphogg]

Ahh, I finally understand your issue. It took me a while. Sorry...

So if we have quantity point in kelvins and we use this value for calculating some derived quantities in SI units and then someone changes the unit to degree Celsius, then all the values will be wrong if we use qp.quantity_from_zero(). Do I understand it correctly? Do you suggest providing qp.quantity_from_zero_in(Unit) instead?

I don't really know the right answer yet; all I'm doing so far is checking candidates to see whether they're unit-safe (or "origin-safe" in this context).

I think this explanation is correct, yes. If we have a quantity point in kelvins, and we convert it to a quantity using something like .quantity_from_zero(), then refactoring to degrees Celsius would break that code, because it's not "origin-safe".

Temperatures are interesting, because there's a well-defined notion of "absolute zero". Often in physics, we'll see "the temperature" (which we are treating as a point) enter into what is clearly a quantity-type equation; what I think is really happening here is that we're implicitly doing $(T - T_0)$, where $T_0$ is absolute zero. Maybe that suggests there should be a free function, quantity_from_absolute_zero(qp), which is defined for temperatures and perhaps also pressures? It's one possibility.

Heights/altitudes is another interesting case, because there's not really an "absolute zero" in the same way. My intuition here is to say that the only valid way to get a quantity from a quantity point is to subtract off some other quantity point. Let's call that a working hypothesis, which could be disproven by a good counter-example.

[mpusz]

Implicit point origin for units that do not predefine one has some issues that we must understand. For example:

EXPLICIT ORIGINS

constexpr struct mean_sea_level : absolute_point_origin<mean_sea_level, isq::altitude> {} mean_sea_level;
constexpr struct home : absolute_point_origin<home, isq::distance> {} home;

// quantity_point<si::metre, mean_sea_level> alt = 42 * m;       // does not compile
// quantity_point<si::kilo<si::metre>, home> airport = 10 * km;  // does not compile
quantity_point<si::metre, mean_sea_level> alt = mean_sea_level + 42 * m;
quantity_point<si::kilo<si::metre>, home> airport = home + 10 * km;

std::cout << alt.quantity_from(mean_sea_level) << "\n";          // 42 m
std::cout << airport.quantity_from(home) << "\n";                // 10 km
// std::cout << alt.quantity_from_zero() << "\n";                // does not compile
// std::cout << airport.quantity_from_zero() << "\n";            // does not compile

// quantity q = alt - airport;                                   // does not compile

Should .quantity_from_zero() compile above? How should it behave? Should it always return a quantity from the absolute point origin, as this origin actually means zero on our measurement scale? Note that if we change one absolute point origin to another one while refactoring, the numerical value does not change as it always specifies the beginning of the scale.

IMPLICIT POINT ORIGINS FOR UNITS-ONLY MODE

quantity_point<si::metre> alt = 42 * m;
quantity_point<si::kilo<si::metre>> airport = 10 * km;
// quantity_point<si::metre> alt = mean_sea_level + 42 * m;       // does not compile
// quantity_point<si::kilo<si::metre>> airport = home + 10 * km;  // does not compile

// std::cout << alt.quantity_from(mean_sea_level) << "\n";        // does not compile
// std::cout << airport.quantity_from(home) << "\n";              // does not compile
std::cout << alt.quantity_from_zero() << "\n";                    // 42 m
std::cout << airport.quantity_from_zero() << "\n";                // 10 km

quantity q = alt - airport;
std::cout << q << "\n";                                           // -9958 m

IMPLICIT POINT ORIGINS FOR TYPED QUANTITIES

quantity_point<isq::altitude[si::metre]> alt = 42 * m;
quantity_point<isq::distance[si::kilo<si::metre>]> airport = 10 * km;
// quantity_point<isq::altitude[si::metre]> alt = mean_sea_level + 42 * m;       // does not compile
// quantity_point<isq::distance[si::kilo<si::metre>]> airport = home + 10 * km;  // does not compile

// std::cout << alt.quantity_from(mean_sea_level) << "\n";                       // does not compile
// std::cout << airport.quantity_from(home) << "\n";                             // does not compile
std::cout << alt.quantity_from_zero() << "\n";                                   // 42 m
std::cout << airport.quantity_from_zero() << "\n";                               // 10 km

// quantity q = alt - airport;                                                   // does not compile

alt - airport does not compile above as the implicit point origins are different (implicit_zeroth_point_origin<isq::altitude> and implicit_zeroth_point_origin<isq::distance>). The error is caused by the fact that isq::altitude is a separate branch from isq::distance (they are incompatible).

This raises the question if implicit_zeroth_point_origin<isq::length> should be somehow considered compatible with implicit_zeroth_point_origin<isq::distance> as isq::distance is isq::length?

[mpusz]

There might also be a mixed approach where we mix implicit points and explicit ones, but in this case, the answer is simple. They should not be compatible with each other. In other words, mean_sea_level and implicit_zeroth_point_origin<isq::altitude> should not be considered compatible.

[mpusz]

To summarize, implicit point origins simplify the usage of points but are not as safe as explicit ones. That is of course, not a surprise and was the design intent.

[JohelEGP]

This raises the question if implicit_zeroth_point_origin<isq::length> should be somehow considered compatible with implicit_zeroth_point_origin<isq::distance> as isq::distance is isq::length?

Yes.

Let's consider path length, "length of a rectifiable curve between two of its points",
distance, "shortest path length between two points in a metric space",
and "home" for the point origin.
A distance, the more specialized quantity, is convertible to path length, its more general quantity.
I would expect a point of distance from home to be convertible to a point of path length from home.

However, the current design of the mp-units library requires a quantity specification when defining an absolute point origin.
But the name of a point origin like "home" can be much more abstract than that.
For example, you can also represent an altitude away from home, or just an arbitrary length away from home.
In my project, I have point origins for "window" and "screen", represented with the concrete types window and screen.
As point origins, they represent the top-left point (0, 0) as the conventional origin that grows down-right.
Although they represent a point, combining them with a Cartesian width or height serves well to describe its position on the axis.

[chiphogg]

Here's an interesting tangent that occurred to me, so I'm breaking it off into a separate thread.

How do quantity points behave when you have two different origins that have no defined relationship at all to each other?

I assume that it would be impossible to convert back and forth between them. If so, that could be really useful!

Here's a use case. Imagine we have a unit/integration testing framework for self-driving, which has a small subset of a road network. We would like to use quantity points to label the positions along the road --- think of them as analogous to "mile markers". But there's a problem when we have two intersecting roads. Each should be labeled with quantity points, but we definitely don't want to mix up points from one road's "frame" with points from the other's! Maybe we can have two origins, main_road_zero and intersecting_road_zero, and we can define all of our "mile markers" in terms of these. If we did that --- and if we did not define a relationship between them --- then the compiler would keep them separate for us, right?

[JohelEGP]

How do quantity points behave when you have two different origins that have no defined relationship at all to each other?

I assume that it would be impossible to convert back and forth between them. If so, that could be really useful!

That's the current behavior for points with different absolute origins.

[JohelEGP]

Gašper Ažman on Price and PriceDelta: https://youtu.be/Jhggz8rtHbk?t=3062.

[mpusz]

BTW, our docs mention this explicitly for a while now: https://mpusz.github.io/mp-units/latest/users_guide/framework_basics/the_affine_space/#points-are-more-common-than-most-of-us-imagine 😉

[mpusz]

Also, we have another finance domain example here: https://mpusz.github.io/mp-units/latest/users_guide/framework_basics/value_conversions/#value-truncating-conversions.

[JohelEGP]

This is to help convince @chiphogg that prices can be points.

[burnpanck]

I'm sure there is no disagreement that prices can be modelled as points. However, should they? I'm not convinced. To me, any point on a scale, where there is a distinct origin, and where the distance to that origin carries "physical" meaning is best modelled as a distance from that point. Does it make sense to multiply prices? Thinking for example about interests paid: these are proportional to the price owed. A proportionality can never stand with respect to a point, but only to the distance. To me, a the rule of thumb is: "does it make sense to add or multiply these quantities (and it is unambiguously clear what is meant)?" If yes, then it should not be a point.

I fully agree with @atomgalaxy that only plausible business logic should compile. However, I can see many cases where prices are plausibly added together even when the price is an intrinsic property of a specific object. The value of a set of such objects is the sum of their prices. But I definitely don't want to prevent someone from modelling prices as a point if the specific problem domain such aggregations of prices are out of scope.

[chiphogg]

I was going to write back, but I think I could hardly have expressed myself better than @burnpanck's comment above.

My point was going to be that a key property of point types is that the values are labels, and the point we decide to label as "zero" is arbitrary. If anyone thinks this is true of prices, then I have a bridge to sell them for a price of "zero". 😉

I was also going to explicitly agree that prices can be modeled as points in certain domains. It just seems to me that what we want here is only a subset of the usual set of "point properties" (such as restricting addition, again, in certain domains), whereas other properties (such as inability to multiply, or freedom to set the zero point) make no sense.

[atomgalaxy]

So, the main issue with prices being *points* is that you shouldn't be adding them, because adding two prices results in a "price for a bundle" as opposed to "price per unit". In other words, I've seen bugs. Basically, price_per_unit * quantity = price_you_pay, but price_per_unit + price_per_unit makes no sense (unless you're doing an interpolation and dividing by number of units right after, which is an operation that *is* defined on point-spaces). so, price_you_pay is a vector space, price_per_unit is a point-space. Still disagree?

…

On Mon, Jan 8, 2024 at 3:54 PM Chip Hogg ***@***.***> wrote: I was going to write back, but I think I could hardly have expressed myself better than @burnpanck <https://github.com/burnpanck>'s comment above. My point was going to be that a key property of point types is that the values are *labels*, and the point we decide to label as "zero" is arbitrary. If anyone thinks this is true of prices, then I have a bridge to sell them for a price of "zero". 😉 I was also going to explicitly agree that prices *can* be modeled as points in certain domains. It just seems to me that what we want here is only a subset of the usual set of "point properties" (such as restricting addition, again, *in certain domains*), whereas other properties (such as inability to multiply, or freedom to set the zero point) make no sense. — Reply to this email directly, view it on GitHub <#514 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5R5JQ6GFHJLUIZTMI673YNQJCFAVCNFSM6AAAAAA66VNUCKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DANJRG4ZDS> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chiphogg]

I think there are two related but separate questions, which we should avoid conflating.

First, "is it useful to prevent adding price-per-unit?" If you as the domain expert say that it is, then I'm more than happy to concede the... er, point. 😅

Next, "are these point types?" Here, I'm not sold yet. Point types should not admit any sensible notion of multiplication. But for price-per-unit, multiplication is well defined and indeed strongly unambiguous. If the price per unit triples, everyone agrees what that means!

The sense I get from this domain is less one of "point types", and more one of "types where we want to prevent accidental addition".

[mpusz]

If we model the price as quantity points we immediately gain lots of safety but also pay with usability issues. Here is a short finance example we were working on with Ari Jort in Kona: https://godbolt.org/z/6v3zG1dfr.

@atomgalaxy, do you see how we could improve the library to make such cases more suitable for your domain?

[atomgalaxy]

Note that price_per_unit * quantity = price you pay, but Price_per_unit * scaling_factor = price_per_unit These are not the same.

…

On Mon, Jan 8, 2024, 18:43 Chip Hogg ***@***.***> wrote: I think there are two related but separate questions, which we should avoid conflating. First, "is it useful to prevent adding price-per-unit?" If you as the domain expert say that it is, then I'm more than happy to concede the... er, point. 😅 Next, "are these point types?" Here, I'm not sold yet. Point types should not admit any sensible notion of multiplication. But for price-per-unit, multiplication is well defined and indeed strongly unambiguous. If the price per unit triples, everyone agrees what that means! The sense I get from this domain is less one of "point types", and more one of "types where we want to prevent accidental addition". — Reply to this email directly, view it on GitHub <#514 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5R5IKKCKGGXXINVTDRL3YNQ44ZAVCNFSM6AAAAAA66VNUCKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DANJUGA2TA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chiphogg]

Yes, quite so. It's the latter that I was intending to discuss, as I think the wording makes reasonably clear ("if the price per unit triples").

And this is the operation which is not defined for point types, but is defined for price per unit.

(By the way: it looks like you're creating a new thread with every reply --- was that intentional?)

[chiphogg]

Also, totally unrelated, but since this is the first time we've interacted --- thank you for all your work on "deducing this"! It's the defining feature of C++23. It's remarkable after all these decades to see a core language feature which solves so many seemingly unrelated problems. It fits so neatly that it feels like it simply should have always been there. Bravo!

[atomgalaxy]

Fundamentally, this is about flexibility in modeling your domain. We ended up with a fairly complete mixin system for operators on a type, but that usually just went as far as points-over-module/ring. We then had macros that defined the rest of the valid operators across types. We needed to model different kinds of price deltas separately, so different fees had different types (and could only be applied once), day-start position was a different type than current day position, etc. This is all for the same instrument. This helped onboard people really quickly because it was easy to see where a newcomer was struggling with the type system, which showed where their understanding of the business was incomplete. To derive requirements from the above: every type can be part of multiple arithmetic structures with outer operations, and making that modeling clear and simple is the killer feature.

…

On Tue, Jan 9, 2024, 09:44 Mateusz Pusz ***@***.***> wrote: If we model the price as quantity points we immediately gain lots of safety but also pay with usability issues. Here is a short finance example we were working on with Ari Jort in Kona: https://godbolt.org/z/6v3zG1dfr. @atomgalaxy <https://github.com/atomgalaxy>, do you see how we could improve the library to make such cases more suitable for your domain? — Reply to this email directly, view it on GitHub <#514 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5R5KXOQX5T36QEYK7HXTYNUGRPAVCNFSM6AAAAAA66VNUCKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DANRSHAYDI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mpusz]

I agree that dedicated types will address the domain than a general-purpose quantities library. This is what @chiphogg was referring to in #514 (reply in thread). However, for people that do not want to implement the entire hierarchy by themselves, do you see any room for improvement in mp-units? For example, should we implement "an interpolation and dividing by number of units right after, which is an operation that is defined on point-spaces"? Do you have some ideas how to specify such interfaces? Some other ideas about things that are lacking or could be improved?

[atomgalaxy]

We have a lerp function in the stdlib, that's defined on point spaces

[mpusz]

Right, we could provide lerp for quantity_point types to do the interpolation. However, I think previously you meant a different operation. Something more like an average (price1 + price2 + price 3 / 3), right? As points can't be added it is not that easy to actually find a good interface for such an operation.

[atomgalaxy]

On Tue, Jan 9, 2024, 01:05 Chip Hogg ***@***.***> wrote: Also, *totally unrelated*, but since this is the first time we've interacted --- thank you for all your work on "deducing this"! It's *the* defining feature of C++23. It's remarkable after all these decades to see a core language feature which solves so many seemingly unrelated problems. It fits so neatly that it feels like it simply should have always been there. Bravo!

Thanks! I'm looking forward to using it myself :). I hope it makes mixins better and cheaper - and this library will definitely benefit from that. As for starting a new thread - I'm just hitting reply-all, not sure what's wrong on GitHub's side. —

…

Reply to this email directly, view it on GitHub <#514 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5R5P3RD5UNBTDHF7DI5LYNSJWHAVCNFSM6AAAAAA66VNUCKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DANJYG43DM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mpusz]

As for starting a new thread - I'm just hitting reply-all, not sure what's
wrong on GitHub's side.

So it seems that when you reply by email, GitHub will always start a new thread for each answer. On the GitHub page for discussions you can chose to either provide a reply to the existing thread or start a new one with "Add a comment" edit box.

[atomgalaxy]

Whatever you wanna call it, it's lerp. Maybe lerp_range(points, weights). That's the op that's defined on points.

…

On Wed, Jan 10, 2024, 10:09 Mateusz Pusz ***@***.***> wrote: Right, we could provide lerp for quantity_point types to do the interpolation. However, I think previously you meant a different operation. Something more like an average (price1 + price2 + price 3 / 3), right? As points can't be added it is not that easy to actually find a good interface for such an operation. — Reply to this email directly, view it on GitHub <#514 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5R5M6Q5XQLDSGSZIMR23YNZSGHAVCNFSM6AAAAAA66VNUCKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DANZXHA3TK> . You are receiving this because you were mentioned.Message ID: ***@***.***>