During the discussion in the SG6 it was raised that that `30 *
absolute<deg_C>` feels wrong, and I tend to agree with that. This was the
only usage of `absolute` so, if multiply syntax should not use it, the
`absolute` can be removed. After that, `30 * delta<deg_C>` looks like a
hack and not a feature.

I am looking for some other solutions that would help here. Maybe we should:
- disallow the multiply syntax for offset units (K, deg_C, deg_F),
- change `delta` to be a functor and call it as `delta<deg_C>(20)` which
produces a `quantity`
- re-add `absolute` to create a `quantity_point` with the same syntax
(e.g., `absolute<deg_C>`)

With the above, we would end up with the following helpers:

```cpp
quantity q1 = 40 * m;
quantity q2 = delta<m>(40);
quantity_point q3 = absolute<m>(40);
quantity q4 = 40 * deg_C; // Compile-time error
quantity q5 = delta<deg_C>(40);
quantity_point q6 = absolute<deg_C>(40);
quantity q7 = 40 * isq::thermodynamic_temperature[deg_C]; // Compile-time
error
quantity q8 = delta<isq::thermodynamic_temperature[deg_C]>(40);
quantity_point q9 = absolute<isq::thermodynamic_temperature[deg_C]>(40);
```

With the proposed change, I hope that is more evident what the following
code does:

```cpp
quantity q = delta<K>(300);
quantity_point qp = absolute<K>(300);
static_cast(q.in(deg_C) != qp.in(deg_C).quantity_from_zero());
```

How do you feel about it? Aren't the two ways to create a quantity too much?

śr., 19 cze 2024 o 14:27 Mateusz Pusz <mateusz.pusz_at_[hidden]> napisał(a):

> I've just implemented something like this in this PR:
> https://github.com/mpusz/mp-units/pull/585. Please let me know if you
> think that is a good idea that solves the problem raised by Tiago
> (accidental error-prone syntax for temperatures). If so, I will merge it
> with the library and update the paper in the next revision.
>
> Best
>
> Mat
>
> śr., 19 cze 2024 o 17:30 Mateusz Pusz <mateusz.pusz_at_[hidden]> napisał(a):
>
>> The `relative` and `absolute` modifiers will be stripped upon
>> construction, so the resulting quantity and quantity_point types will just
>> use the underlying unit in its instantiation.
>>
>> śr., 19 cze 2024 o 17:29 Mateusz Pusz <mateusz.pusz_at_[hidden]>
>> napisał(a):
>>
>>> 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?
>>>
>>> śr., 19 cze 2024 o 16:07 Mateusz Pusz <mateusz.pusz_at_[hidden]>
>>> napisał(a):
>>>
>>>> Predefining instances of quantity and quantity_point have some issues:
>>>>
>>>> 1. We have to pick a representation type that will suit all the users.
>>>> 2. We can't pass such instances to .in() member function.
>>>> 3. It might be hard to spell the type of a class template in the
>>>> interface.
>>>> 4. We might have issues in using a hierarchy of strong quantity types
>>>> for temperatures (users should be allowed to "inherit" and easily use their
>>>> own more specialized temperatures from the quantity_spec provided in the
>>>> library)
>>>>
>>>> śr., 19 cze 2024 o 15:43 Sebastian Wittmeier via Std-Proposals <
>>>> std-proposals_at_[hidden]> napisał(a):
>>>>
>>>>> deg_F could be a quantity_point instance
>>>>>
>>>>> and
>>>>>
>>>>> rel_deg_F a quantity instance
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Mateusz Pusz <mateusz.pusz_at_[hidden]>
>>>>> *Gesendet:* Mi 19.06.2024 15:34
>>>>> *Betreff:* Re: [std-proposals] On the standardization of mp-units
>>>>> P3045R1
>>>>> *An:* std-proposals_at_[hidden];
>>>>> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>>>>> But are those two objects/variables of the same type, so they have the
>>>>> same behavior?
>>>>>
>>>>> śr., 19 cze 2024 o 15:31 Sebastian Wittmeier via Std-Proposals <
>>>>> std-proposals_at_[hidden]> napisał(a):
>>>>>
>>>>> Two units? deg_F and rel_deg_F
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> only rel_deg_F can be used for multiplication
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> so
>>>>>
>>>>> gp.in(deg_F).quantity_from_zero() is possible
>>>>>
>>>>>
>>>>>
>>>>> and
>>>>>
>>>>>
>>>>>
>>>>> auto t60 = 60 * rel_deg_F
>>>>>
>>>>>
>>>>>
>>>>> is needed
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Mateusz Pusz <mateusz.pusz_at_[hidden]>
>>>>> *Gesendet:* Mi 19.06.2024 13:45
>>>>> *Betreff:* Re: [std-proposals] On the standardization of mp-units
>>>>> P3045R1
>>>>> *An:* std-proposals_at_[hidden];
>>>>> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>>>>> While writing the answer to Ville, I realized that there is one more
>>>>> issue. We will have to write:
>>>>>
>>>>> quantity_point qp(20 * rel_deg_C);
>>>>> std::cout << qp.in(rel_deg_F).quantity_from_zero();
>>>>>
>>>>> Which might be confusing for scaling quantity_point. Also, we will
>>>>> need to add `rel_` to Kelvins and all its prefixes for the same reason as
>>>>> in the other email.
>>>>>
>>>>> śr., 19 cze 2024 o 13:26 Sebastian Wittmeier via Std-Proposals <
>>>>> std-proposals_at_[hidden]> napisał(a):
>>>>>
>>>>> For the specific heat capacity, rel_deg_C is correct anyway, as it is
>>>>> not related to the absolute temperature, is it?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> For the ideal gas law, R, however, is more problematic:
>>>>>
>>>>>
>>>>>
>>>>> auto R = 8.314 * N * m / (rel_deg_C * mol)
>>>>>
>>>>>
>>>>>
>>>>> All or all except one unit have to be quantity points. But they are
>>>>> all quantities.
>>>>>
>>>>> But one cannot (with the current library) calculate with quantity
>>>>> points.
>>>>>
>>>>>
>>>>>
>>>>> That is an error, which was in mp-units before.
>>>>>
>>>>>
>>>>>
>>>>> I find it less problematic at the formulas than when defining the
>>>>> input value, because beginners would rather define values than formulas.
>>>>> Formulas are hopefully tested at least with one set of values.
>>>>>
>>>>> And if an absolute temperature is provided as an input with type
>>>>> quantity point then the code for the formula has to deal with it by
>>>>> converting back to a relative temperature (e.g. relative to T0)..
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Mateusz Pusz <mateusz.pusz_at_[hidden]>
>>>>> *Gesendet:* Mi 19.06.2024 13:01
>>>>> *Betreff:* Re: [std-proposals] On the standardization of mp-units
>>>>> P3045R1
>>>>> *An:* std-proposals_at_[hidden];
>>>>> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>>>>> Hi Sebastian,
>>>>>
>>>>> You are right, and that is actually a really good idea! :-)
>>>>> Sure, we can do that.
>>>>>
>>>>> The only downside I see is that we will have to write something like
>>>>> the below for the specific heat capacity or similar units:
>>>>>
>>>>> quantity<J / (kg * rel_deg_C)> specific_heat_capacity = 42 * J / (kg
>>>>> * rel_deg_C);
>>>>>
>>>>> śr., 19 cze 2024 o 12:24 Sebastian Wittmeier via Std-Proposals <
>>>>> std-proposals_at_[hidden]> napisał(a):
>>>>>
>>>>> Hi Mateusz,
>>>>>
>>>>>
>>>>>
>>>>> If I understand correctly, the library introduces types and objects
>>>>> for the units of the same name.
>>>>>
>>>>>
>>>>>
>>>>> If one makes an exception from this rule for °C:
>>>>>
>>>>> - The type is called `deg_C`
>>>>>
>>>>> - The object is called `rel_deg_C`
>>>>>
>>>>> - (+ the same for Fahrenheit)
>>>>>
>>>>>
>>>>>
>>>>> Then
>>>>>
>>>>>
>>>>>
>>>>> auto t20 = (20 * rel_deg_C)
>>>>>
>>>>> is a quantity of 20°C temperature difference and of type
>>>>> `quantity<deg_C, int>`
>>>>>
>>>>>
>>>>>
>>>>> auto at20a = quantity_point qp1(t20)
>>>>>
>>>>> or
>>>>>
>>>>> auto at20b = zeroth_degree_Celsius + t20
>>>>>
>>>>>
>>>>>
>>>>> are quantity points of 20°C absolute temperature and of type
>>>>> quantity_point<deg_C, ice_point, int>
>>>>>
>>>>>
>>>>>
>>>>> Then we do not need 2 units or 2 types
>>>>>
>>>>> As far as I understand the same name was used for simplicity and
>>>>> better compiler error messages, should still be similar enough and clear
>>>>> enough
>>>>>
>>>>> The internal type makes sense both for quantity and quantity point
>>>>>
>>>>> We keep full genericity and no actual special casing for temperature
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Mateusz Pusz <mateusz.pusz_at_[hidden]>
>>>>> *Gesendet:* Mi 19.06.2024 08:35
>>>>> *Betreff:* Re: [std-proposals] On the standardization of mp-units
>>>>> P3045R1
>>>>> *An:* std-proposals_at_[hidden];
>>>>> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>>>>> Unfortunately, there are some other issues here as well. If we
>>>>> introduce two independent units like rel_deg_C and abs_deg_C we will have
>>>>> to make them somehow aware of each other and support this in the framework.
>>>>> Let's see the following code:
>>>>>
>>>>> quantity_point qp1(20 * rel_deg_C); // should instantiate
>>>>> quantity_point<abs_deg_C, ice_point, int>
>>>>> quantity_point qp2(15 * rel_deg_C); // should instantiate
>>>>> quantity_point<abs_deg_C, ice_point, int>
>>>>> quantity q = qp1 - qp2; // should instantiate quantity<rel_deg_C, int>
>>>>>
>>>>> wt., 18 cze 2024 o 21:44 Sebastian Wittmeier via Std-Proposals <
>>>>> std-proposals_at_[hidden]> napisał(a):
>>>>>
>>>>> Ok, than really use two units: rel_deg_C and abs_deg_C.
>>>>>
>>>>>
>>>>>
>>>>> quantity_point(...).in(abs_deg_C) would be accepted
>>>>> quantity_point(...).in(rel_deg_C) would not
>>>>>
>>>>>
>>>>>
>>>>> So no longer confusing.
>>>>>
>>>>>
>>>>>
>>>>> Similar for all other usages: The one making sense works.
>>>>>
>>>>> The one not making sense is not accepted.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Why special-case temperature compared to other units?
>>>>>
>>>>> ============================================
>>>>>
>>>>> temperatures are used very often as quantity point,
>>>>>
>>>>> the quantity point has a general physical meaning (as the reference is
>>>>> defined),
>>>>>
>>>>> and the reference point is != 0 (at least for °C and °F unlike K).
>>>>>
>>>>>
>>>>>
>>>>> What about generic code?
>>>>>
>>>>> ====================
>>>>>
>>>>> Generic code should be able to access quantity and quantity point in
>>>>> an identical (but possibly more verbose) way for all units, temperature and
>>>>> others
>>>>>
>>>>>
>>>>>
>>>>> What about possible other units similar to temperature?
>>>>>
>>>>> ============================================
>>>>>
>>>>> Perhaps the library should allow this same special-casing for
>>>>> user-defined units, too.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Mateusz Pusz <mateusz.pusz_at_[hidden]>
>>>>> *Gesendet:* Di 18.06.2024 16:56
>>>>> *Betreff:* Re: [std-proposals] On the standardization of mp-units
>>>>> P3045R1
>>>>> *An:* std-proposals_at_[hidden];
>>>>> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>>>>> Unfortunately, this is not that easy. Let's see this example:
>>>>>
>>>>> quantity_point temp(300. * K);
>>>>> std::cout << temp.in(deg_C).quantity_from_zero() << " " << temp.in(deg_F).quantity_from_zero()
>>>>> << "\n";
>>>>>
>>>>>
>>>>> This prints:
>>>>>
>>>>> 26.85 °C 80.33 °F
>>>>>
>>>>> Using `rel_deg_C` and `rel_deg_F` would be confusing here.
>>>>>
>>>>> Best
>>>>>
>>>>> Mat
>>>>>
>>>>> wt., 18 cze 2024 o 16:49 Sebastian Wittmeier via Std-Proposals <
>>>>> std-proposals_at_[hidden]> napisał(a):
>>>>>
>>>>> Then just change deg_C to rel_deg_C to prevent misuse
>>>>>
>>>>> so
>>>>>
>>>>>
>>>>>
>>>>> 23 * rel_deg_C
>>>>>
>>>>>
>>>>>
>>>>> would work for a temperature difference and
>>>>>
>>>>>
>>>>>
>>>>> quantity_point(28.0 * rel_deg_C)
>>>>>
>>>>>
>>>>>
>>>>> would be needed for the absolute temperature of 301K.
>>>>>
>>>>> One can always later on define a nicer-looking shortcut for the second
>>>>> one.
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Mateusz Pusz <mateusz.pusz_at_[hidden]>
>>>>> *Gesendet:* Di 18.06.2024 16:37
>>>>> *Betreff:* Re: [std-proposals] On the standardization of mp-units
>>>>> P3045R1
>>>>> *An:* std-proposals_at_[hidden];
>>>>> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>>>>> `deg_C` is just a symbol for the `si::degree_Celsius` unit. We could
>>>>> consider not providing Celsius and Fahrenheit units at all, but this would
>>>>> make many users unhappy. Degree Celsius is one of the official SI units (
>>>>> https://en.wikipedia.org/wiki/International_System_of_Units#Derived_units),
>>>>> and not providing support for it would be problematic.
>>>>>
>>>>> The affine space abstraction is the best solution for the temperature
>>>>> problem according to our knowledge and experience:
>>>>> - when we state that today is 4 degree Celsius warmer than yesterday
>>>>> we mean the `quantity`
>>>>> - when we state that today temperature is 23 degree Celsius we mean
>>>>> the `quantity_point`
>>>>>
>>>>> To prevent errors and to be consistent with maths, quantity_point does
>>>>> not multiply and divide with other units. We can only add or subtract an
>>>>> offset from it or subtract another point to get a quantity.
>>>>> Multiply syntax (e.g., 23 * deg_C) always results in a quantity and
>>>>> not a quantity_point.
>>>>>
>>>>> For the sake of correctness, we could add a dirty hack to the generic
>>>>> framework that would disable the multiply syntax for temperatures only.
>>>>> With this, the user would always have to write something like this:
>>>>>
>>>>> quantity_point temperature(quantity(28.0, deg_C)); //
>>>>> zeroth_degree_Celsius point origin provided by default here
>>>>> quantity temperature_delta(3.0, deg_C);
>>>>>
>>>>>
>>>>> But I am not sure if this would be better.
>>>>>
>>>>> Best
>>>>>
>>>>> Mat
>>>>>
>>>>> wt., 18 cze 2024 o 16:18 Sebastian Wittmeier via Std-Proposals <
>>>>> std-proposals_at_[hidden]> napisał(a):
>>>>>
>>>>> Hi Mateusz,
>>>>>
>>>>>
>>>>>
>>>>> how about the (in one of the messages by me today) suggested
>>>>>
>>>>>
>>>>>
>>>>> rel_deg_C is a quantity
>>>>>
>>>>>
>>>>>
>>>>> vs.
>>>>>
>>>>>
>>>>>
>>>>> abs_deg_C is a quantity_point
>>>>>
>>>>>
>>>>>
>>>>> ?
>>>>>
>>>>>
>>>>>
>>>>> That would prevent bugs, which are easy to introduce for temperature
>>>>> by making that distinction explicit.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Or alternative spellings: deg_rel_C / deg_C_rel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Mateusz Pusz via Std-Proposals <std-proposals_at_[hidden]>
>>>>> *Gesendet:* Di 18.06.2024 15:54
>>>>> *Betreff:* Re: [std-proposals] On the standardization of mp-units
>>>>> P3045R1
>>>>> *An:* std-proposals_at_[hidden];
>>>>> *CC:* Mateusz Pusz <mateusz.pusz_at_[hidden]>; Chip Hogg
>>>>> <chogg_at_[hidden]>; Johel Ernesto Guerrero Peña <johelegp_at_[hidden]>;
>>>>> Anthony Williams <anthony_at_[hidden]>;
>>>>> Hi,
>>>>>
>>>>> Tiago, some time has passed since your last complaint about the same
>>>>> problem. We invited you to our internal meeting, listened to your concerns,
>>>>> and discussed how we can improve here. As you know, the answer was not
>>>>> found at the meeting. Additionally, you stated that you don't want to work
>>>>> to contribute to our proposal and repository and that you will come back
>>>>> with a better interface soon. More info can be found here:
>>>>> https://github.com/mpusz/mp-units/discussions/552. Did you manage to
>>>>> find a better solution to this problem? If so we are open to rediscuss your
>>>>> solution whenever you are ready.
>>>>>
>>>>> For all other participants of this mailing list, here is a correct
>>>>> solution:
>>>>>
>>>>> #include <mp-units/ostream.h>
>>>>> #include <mp-units/systems/si.h>
>>>>> #include <iostream>
>>>>>
>>>>> using namespace mp_units;
>>>>>
>>>>> inline constexpr struct atmospheric_pressure final : named_unit<"atm",
>>>>> mag<101'325> * si::pascal> {} atmospheric_pressure;
>>>>>
>>>>> int main()
>>>>> {
>>>>> using namespace mp_units::si::unit_symbols;
>>>>>
>>>>> quantity Volume = 1.0 * m3;
>>>>> quantity_point Temperature(28.0 * deg_C);
>>>>> quantity n_ = 0.04401 * kg / mol;
>>>>> quantity R_boltzman = 8.314 * N * m / (K * mol);
>>>>> quantity mass = 40.0 * kg;
>>>>> quantity Pressure = R_boltzman *
>>>>> Temperature.in(K).quantity_from_zero() * mass / n_ / Volume;
>>>>> std::cout << Pressure.in(Pa) << "(" <<
>>>>> Pressure.in(atmospheric_pressure) << ")\n";
>>>>> }
>>>>> https://godbolt.org/z/E8bf51hKG
>>>>>
>>>>> Temperatures are tricky, and there is no good default here. People
>>>>> often mean either a point or a difference, depending on the context. In
>>>>> case anyone has an idea on how to improve, we are open to feedback.
>>>>>
>>>>> Best
>>>>>
>>>>> Mat
>>>>>
>>>>> wt., 18 cze 2024 o 15:30 Sebastian Wittmeier via Std-Proposals <
>>>>> std-proposals_at_[hidden]> napisał(a):
>>>>>
>>>>> How about the following scales? Are they also an issue?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - Time (Calendar) relative to either anno domini or Unix time?
>>>>> - Position Coordinate relative to Greenwich?
>>>>> - Electric Potential relative to earth potential?
>>>>> - pH, pKa, pKb scales relative to a neutrality of 7?
>>>>> - Decibels, phon and sone relative to threshold of human hearing?
>>>>> - Pressure (hydraulic or blood) relative to atmospheric pressure?
>>>>> - Altitude relative to sea level?
>>>>>
>>>>> -> For pressure and altitude there are lots of other scales, e.g.
>>>>> used in aviation
>>>>> - Richter scale relative to detectable earthquakes?
>>>>> - Beaufort relative to calm wind instead of zero wind?
>>>>> - Borg physical exertion not starting at zero?
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>>
>>>>> wt., 18 cze 2024 o 15:44 Tiago Freire via Std-Proposals <
>>>>> std-proposals_at_[hidden]> napisał(a):
>>>>>
>>>>> I understand what the problem is, that is why I’m bringing it forward.
>>>>>
>>>>> My concerned is that I haven’t written any code that anyone wouldn’t
>>>>> have written and got the wrong answer.
>>>>>
>>>>>
>>>>>
>>>>> > An absolute value in the paper is a quantity_point, a possibly
>>>>> relative value is a quantity.
>>>>>
>>>>>
>>>>>
>>>>> Which is a perspective, not convinced that it is the right thing. But
>>>>> That also poses the question, volume is also an absolute value, so is the
>>>>> mass, pressure, etc..
>>>>>
>>>>>
>>>>>
>>>>> Which means that the right way to write it would be this:
>>>>>
>>>>> ```
>>>>>
>>>>> quantity_point Volume {1.0 * m*m*m};
>>>>>
>>>>> quantity_point Temperature {si::ice_point + 28.0 * deg_C};
>>>>>
>>>>> quantity_point n_{0.04401 * kg / mol};
>>>>>
>>>>> quantity R_boltzman = 8.314 * N * m / (K * mol);
>>>>>
>>>>> quantity_point mass {40.0 * kg};
>>>>>
>>>>> quantity_point P = R_boltzman * Temperature * mass / n_ / Volume;
>>>>>
>>>>> std::cout << Pressure << std::endl;
>>>>>
>>>>> ```
>>>>>
>>>>>
>>>>>
>>>>> But this doesn’t compile because quantity_point can’t math.
>>>>>
>>>>> In order to get it to compile you would have to do this instead:
>>>>>
>>>>> ```
>>>>>
>>>>> quantity_point Pressure = quantity_point{0.0*Pa} + R_boltzman *
>>>>> (Temperature - mp_units::si::absolute_zero) * (mass -
>>>>> quantity_point{0.0*kg}) / (n_ - quantity_point{0.0*kg / mol}) / (Volume -
>>>>> quantity_point{0.0* m*m*m});
>>>>>
>>>>> ```
>>>>>
>>>>> Which doesn’t even module the problem properly because the values in
>>>>> PV=nRT are supposed to be absolute values, not deltas.
>>>>>
>>>>>
>>>>>
>>>>> Hence it raises the question, doing what it seems obvious is the wrong
>>>>> thing (thus questionably safe), and doing the right thing is kind of hard
>>>>> (thus questionably user-friendly). But that what is expected as the correct
>>>>> way to use it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On
>>>>> Behalf Of *Sebastian Wittmeier via Std-Proposals
>>>>> *Sent:* Tuesday, June 18, 2024 15:03
>>>>> *To:* std-proposals_at_[hidden]
>>>>> *Cc:* Sebastian Wittmeier <wittmeier_at_[hidden]>
>>>>> *Subject:* Re: [std-proposals] On the standardization of mp-units
>>>>> P3045R1
>>>>>
>>>>>
>>>>>
>>>>> You are specifically talking about
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3045r1.html#potential-surprises-while-working-with-temperatures
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Discussing the difficulty, when to use a difference in temperature or
>>>>> an absolute temperature.
>>>>>
>>>>>
>>>>>
>>>>> An absolute value in the paper is a quantity_point, a possibly
>>>>> relative value is a quantity.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If I understand correctly, in the current paper to initialize and use
>>>>> absolute temperatures
>>>>>
>>>>>
>>>>>
>>>>> quantity_point qp2 = (isq::Celsius_temperature(28.0 * deg_C)).in(K)
>>>>>
>>>>> and
>>>>>
>>>>> qp2.quantity_from_zero()
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> would have to be used instead of
>>>>>
>>>>>
>>>>>
>>>>> quantity Temperature = (28.0 * deg_C).in(K);
>>>>>
>>>>>
>>>>>
>>>>> The paper also says
>>>>>
>>>>>
>>>>>
>>>>> "We have added the Celsius temperature quantity type for completeness
>>>>> and to gain more experience with it. Still, maybe a good decision would be
>>>>> to skip it in the standardization process not to confuse users."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Sebastian Wittmeier <wittmeier_at_[hidden]>
>>>>> *Gesendet:* Di 18.06.2024 14:42
>>>>> *Betreff:* AW: [std-proposals] On the standardization of mp-units
>>>>> P3045R1
>>>>> *An:* std-proposals_at_[hidden];
>>>>>
>>>>> Hi Tiago,
>>>>>
>>>>> where does this difference of 11x come from?
>>>>>
>>>>> The temperature with 28°C vs. 301K?
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> *Von:* Tiago Freire via Std-Proposals <std-proposals_at_[hidden]>
>>>>> *Gesendet:* Di 18.06.2024 14:28
>>>>> *Betreff:* [std-proposals] On the standardization of mp-units P3045R1
>>>>> *An:* std-proposals_at_[hidden];
>>>>> *CC:* Tiago Freire <tmiguelf_at_[hidden]>;
>>>>>
>>>>> Hi, I will be participating in St. Louis.
>>>>>
>>>>> And one of the papers that interested me was P3045R1, unfortunately I
>>>>> may or may not be on time to participate in this particular session.
>>>>>
>>>>>
>>>>>
>>>>> There’s this question that I would like an answer too, and I wonder if
>>>>> there is anyone who will be attending St. Louis who would be willing to
>>>>> make this question on my behalf:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> A lab worker puts in 40Kg of dry ice into a 1 cubic meter pressure
>>>>> tank rated for 10atm, they then vacuum the tank and seal it.
>>>>>
>>>>> As the CO2 warms up to room temperature (which at a specific date was
>>>>> 28°C) it evaporates, and eventually following the ideal gas law:
>>>>>
>>>>> PV=nRT
>>>>>
>>>>>
>>>>>
>>>>> Is this setup dangerous?
>>>>>
>>>>>
>>>>>
>>>>> Using mp-units (with the exact same design as the one being proposed
>>>>> for standardization) to solve this problem:
>>>>>
>>>>>
>>>>>
>>>>> ```
>>>>>
>>>>> quantity Volume = 1.0 * m*m*m;
>>>>>
>>>>> quantity Temperature = (28.0 * deg_C).in(K);
>>>>>
>>>>> quantity n_ = 0.04401 * kg / mol;
>>>>>
>>>>> quantity R_boltzman = 8.314 * N * m / (K * mol);
>>>>>
>>>>> quantity mass = 40.0 * kg;
>>>>>
>>>>> quantity Pressure = R_boltzman * Temperature * mass / n_ / Volume;
>>>>>
>>>>> std::cout << Pressure << std::endl;
>>>>>
>>>>> ```
>>>>>
>>>>>
>>>>>
>>>>> We get the following result:
>>>>>
>>>>> `211581 N/m2`
>>>>>
>>>>> (=211.581kPa = 2,09 atm)
>>>>>
>>>>> But the correct answer is actually: 2275.629kPa = 22.5 atm
>>>>>
>>>>> (11 time s higher than what mp-units calculated)
>>>>>
>>>>>
>>>>>
>>>>> How is this considered a design feature and not a bug? (note that
>>>>> other similar libraries don’t have this problem)
>>>>>
>>>>> And how do the authors think this design choice impacts on safety and
>>>>> user-friendliness?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>> -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>> --
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>