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
>>>>
>>>