Well, it depends on how you want to model this. Arthur wanted those two to
be subtractible, so I implemented them this way.

> ISA altitude or pressure altitude (used often in aeronautics), these
things are unconvertible to each other, you just can’t do it!

If that is your intent, then replace `quantity` with a `quantity_point`.
You will not be able to subtract them as they will have disjoint origins.
Unless, again, you provide a common origin for them.

I know that you disagree, but affine space abstractions have many good use
cases in units library and many people find them useful. As we saw in this
thread, some even say, that it is a mandatory feature of the library.

Best

Mat

śr., 19 cze 2024 o 20:50 Tiago Freire <tmiguelf_at_[hidden]> napisał(a):

> >> Can the type system actually help us solve this problem at all? *My
> impression* is that mp_units doesn't help us solve this problem.
>
> > Sure! This is the solution with mp-units:
>
>
>
> It doesn’t. ASL is too superficial a problem, when you start to get to
> things like ISA altitude or pressure altitude (used often in aeronautics),
> these things are unconvertible to each other, you just can’t do it! Or when
> you get to things like datums, where references are not just offset to each
> other, but they are also rotated, and it is a problem that can only be
> solved in R3, quantity_point is a patch that only works in R1. It can only
> get you so far.
>
> But here’s the good news, you don’t actually have to solve this problem,
> and there is where things went wrong.
>
>
>
> It’s an idea, may have some usage, but as I have stated affine spaces is a
> problem that is entirely unrelated to a unit system. In my opinion the only
> thing that a unit system needs is to have a metric, the ability to manage
> different dimensions, be able to convert between units of the same
> dimension, or correlate units to form new dimensions. It shouldn’t try to
> do anything else, but because it did it is crumbling under the weight of
> its own complexity.
>
> Distinguishing between “absolute” and “relative” units, totally
> unnecessary, all lengths are the same. There’s are complications to handle
> things like temperatures, but quantity_point or affine spaces was never the
> solution, it’s s a make shift raft, it got this far but you have to
> recognize that the raft is sinking and you are unable to patch this hole.
> It’s not entirely your fault, ISO 80000 has really dropped the ball on this
> one, and anyone in good faith trying to follow it to the letter was always
> going to get a bloody nose.
>
> Any design that was ever going to stand a chance would have to recognize
> this.
>
>
>
>
>
>
>
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On Behalf
> Of *Mateusz Pusz via Std-Proposals
> *Sent:* Wednesday, June 19, 2024 18:55
> *To:* Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> *Cc:* Mateusz Pusz <mateusz.pusz_at_[hidden]>;
> std-proposals_at_[hidden]
> *Subject:* Re: [std-proposals] On the standardization of mp-units P3045R1
>
>
>
> Hi Arthur,
>
>
>
> I would not like to start new discussions here until we address the issues
> discussed before. However, I will briefly answer some of your concerns
> here. If you would like to discuss this in more detail, could you please
> open a new discussion thread on the reflector?
>
>
>
> It is fine to decide that we do not want units in the Standard Library.
> But please decide that now and not five years from now when all the
> contributors to the proposals will spend hundreds of hours working on it.
> This is what I asked a few meetings ago in LEWG, and the answer was to go
> ahead, as it seems that we want it standardized. The authors spent a lot of
> time writing proposals already since then.
>
>
>
> I could argue that every measurement can (but does not have to) be modeled
> as a quantity point, even for length and time. For length, you read the
> value on the ruler or the odometer (notice that you do not have to zero the
> ruler or the odometer to read the value). For time, you read the value of a
> stopwatch. If you want to know how much time has passed or how long
> something is, you subtract the read value from another value read in a
> different measurement. However, it does not mean we do not need quantities.
> If we want to find out how different readouts differ, we subtract them to
> get a quantity.
>
>
>
> > Can the type system actually help us solve this problem at all? *My
> impression* is that mp_units doesn't help us solve this problem.
>
>
>
> Sure! This is the solution with mp-units:
>
>
>
> inline constexpr struct altitude_above_sea_level final :
> quantity_spec<isq::altitude> {} altitude_above_sea_level;
>
> inline constexpr struct altitude_above_terrain final :
> quantity_spec<isq::altitude> {} altitude_above_terrain;
>
> inline constexpr struct height_of_the_terrain_above_sea_level final :
> quantity_spec<isq::height> {} height_of_the_terrain_above_sea_level;
>
>
>
> QuantityOf<height_of_the_terrain_above_sea_level> auto
>
> get_height_of_the_terrain_above_sea_level(QuantityOf<altitude_above_sea_level>
> auto asl,
>
>
> QuantityOf<altitude_above_terrain> auto aat)
>
> {
>
> return height_of_the_terrain_above_sea_level(asl - aat);
>
> }
>
>
>
> int main()
>
> {
>
> using namespace mp_units::si::unit_symbols;
>
>
>
> quantity asl = altitude_above_sea_level(1340 * m);
>
> quantity aat = altitude_above_terrain(340 * m);
>
> quantity res1 = get_height_of_the_terrain_above_sea_level(asl, aat);
>
> // quantity res2 = get_height_of_the_terrain_above_sea_level(aat, asl);
> // Compile-time error
>
> std::cout << res1 << "\n";
>
> }
>
>
>
> https://godbolt.org/z/193afPe4K
>
>
>
> śr., 19 cze 2024 o 18:13 Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> napisał(a):
>
> On Wed, Jun 19, 2024 at 11:29 AM Mateusz Pusz via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> I have an alternative proposal.
>
>
>
> Let's consider adding `alternative(Reference)` and `relative(Reference)`
> modifiers that will influence how:
>
>
>
> - multiply syntax works
>
> - limit invalid use cases for quantity and quantity_point.
>
>
>
> Here are the main points of this new design:
>
> 1. All references/units that do not specify point origin (are not offset
> units) would be considered `relative` by default. This means that `42 * m`
> will create a `quantity` and would be the same as calling `42 *
> relative(m)`.
>
> 2. Multiply syntax could be extended to allow quantity_point creation with
> the `42 * absolute(m)` syntax. This will provide an implicit zeroth point
> origin.
>
> 3. For units that specify a point origin (kelvin, degree_Celsius, and
> degree_Fahrenheit), the user would always need to specify a modifier. This
> means that:
>
> - `4 * deg_C` does not compile
>
> - `4 * relative(deg_C)` creates a `quantity`
>
> - `4 * absolute(deg_C)` creates a `quantity_point`
>
> 4. Constrain constructors of quantity or quantity_point to require the
> same:
>
>
>
> quantity q1(4, m); // OK
> quantity q2(4, relative(m)); // OK
> quantity q3(4, absolute(m)); // Compile-time error
> quantity_point qp1(4, m); // OK
>
> quantity_point qp2(4, relative(m)); // Compile-time error
> quantity_point qp3(4, absolute(m)); // OK
>
>
>
> quantity q4(4, deg_C); // Compile-time error
> quantity q5(4, relative(deg_C)); // OK
> quantity q6(4, absolute(deg_C)); // Compile-time error
> quantity_point qp4(4, deg_C); // Compile-time error
>
> quantity_point qp5(4, relative(deg_C)); // Compile-time error
> quantity_point qp6(4, absolute(deg_C)); // OK
>
>
>
> Please note the above would also apply to Kelvin and Fahrenheit.
>
>
>
> Does it solve the issue discussed here?
>
>
>
> FWIW, I think:
>
> - The WG21 discussion process might be good for mp_units' health, but
> ultimately I don't think mp_units belongs in the STL.
>
> - (As Mateusz knows,) personally I'm enamored of absl::Duration's minimalist
> design <https://abseil.io/docs/cpp/guides/time#time-durations>, where you
> have strong typing for the *dimension* algebra (which is irreducible
> complexity) but the library makes a sensible-in-context choice of units
> (e.g. seconds) and representation types (e.g. `double`) and your program is
> happy with that choice or else you pick a different library to use. As with
> type-erasure types, there are just too many "knobs" to make something that
> *everyone* will be happy with. (That's how we ended up with
> `std::function` and `std::copyable_function`, as well as another ~3
> standard type-erasure types.)
>
> - The idea of affine spaces is indeed key — it is indispensable. Almost
> all of the "new" ideas in this thread have been simply reinventing or
> renaming the two fundamentals `quantity` (delta, relative) and
> `quantity_point` (absolute).
>
> - IMO, Mateusz' informally proposed names `relative` and `absolute` are
> not good, because they are exactly the opposite of how I'd explain them to
> a layman. A temperature delta of 4 degrees (C/K) is *absolute*; it has a
> physical meaning. Now, if you take that delta *relative* to some
> arbitrary origin — e.g. the freezing point of water — then you get the
> temperature reading on a human thermometer (the thing Mateusz informally
> proposed to call `absolute`, even though the way we got it was to add our
> delta *relative* to something else). Now, personally I wouldn't be
> opposed to calling deltas by the name `delta` somehow — e.g. `4 * delta_m`
> — but I don't think that buys any clarity.
>
> - In fact, temperature (like calendar) seems to be *special*, in that we
> have several human-invented origin points (epochs) relative to which you
> might want to represent a temperature (date). We absolutely do not have
> that for e.g. meters, or (in the physical realm) seconds.
>
> - But meters and seconds are special because they were invented
> specifically to measure deltas in spacetime. They're the only two units
> that work *that* way. Most other units *seem* to measure
> "quantity_points" by default: This object weighs *absolutely* 4kg, not
> "4kg more than a weightless object." I'm applying *absolutely* 4Nm of
> torque (or, hmm, *is* it really that I'm applying "a delta of 4Nm more
> than there would have been without my input"?)
>
> - It's not intuitively 100% obvious to me whether we have a natural
> "origin" for kilograms (i.e. "this object's mass is *absolutely* 4kg") or
> whether that's just an abuse of notation (like saying "this event took
> *absolutely* 42 seconds" when what you mean was "the *delta* between this
> event's start and end was 42 seconds"). If we understood that point, it
> might be easier to talk about the whole system.
>
>
>
> Finally, since I'm here, I'll mention my one big concern with mp_units'
> design even though it's new to the thread AFAIK:
>
> - I think anyone *converting units* is already in a state of sin, so I'm
> not too worried about that part. And I like the (high-level) design for *preventing
> accidental conversions of dimension*. I'm very concerned, though, with
> the idea of managing what might be called "soft" dimensions:
> altitude-above-sea-level and altitude-above-terrain are measured in exactly
> the same dimension (length), the same units (meters), in the same direction
> (height), even with a very similar name (altitude), in fact we sometimes
> want to do mixed-mode math on them (the one minus the other equals the
> height of the terrain above sea level)... but still, it is catastrophic to
> confuse them. Can the type system actually help us solve this problem at
> all? *My impression* is that mp_units doesn't help us solve this problem.
> (Although it does help us with other problems, such as mixing up altitude
> with rate-of-descent, because the dimensions/units are different in that
> case.) It's not clear to me whether this indicates "we have half a
> solution, which indicates we should keep searching for the whole solution,"
> or merely "that's a second problem entirely; the first solution is still
> worthwhile for the first problem."
>
>
>
> But I don't think any of this is pro or con "should mp_units go into the
> STL?". I'm pretty firmly against its going into the STL either way. This
> designy stuff is all about "can we come up with a minorly tweaked design
> that improves mp_units?" and "can we come up with a majorly different
> design that is self-consistent at all, or does every alternative design run
> into serious problems?" (I suspect the answer to the former is "no, not
> really" and the answer to the latter is "yes, plausible alternative designs
> are a dime a dozen.")
>
>
>
> my $.02,
>
> –Arthur
>
>