C++ Logo

std-proposals

Advanced search

Re: [std-proposals] On the standardization of mp-units P3045R1

From: Mateusz Pusz <mateusz.pusz_at_[hidden]>
Date: Wed, 19 Jun 2024 09:37:28 +0200
> The answer is... no one would ever do this!
> Every single time that you see °C combined with any other unit (like in
J/(kg °C)) it always means the same thing as Kelvin.

Right, because in most formulas (if I am not wrong), the temperature in
Celsius is a delta and not a temperature point. This is why `quantity` is a
good default for those and not `quantity_point`.

Let's try to summarize the discussion we had so far.

First, thanks for providing a concrete example and raising the issue.
Discussions like this are really important and provide us with vital design
feedback. Temperatures are hard, and that is why none of the libraries on
the market has a perfect solution for them. But let's try to improve here.

It seems that the main issue here is that `10 * deg_C` may be error-prone
for less experienced users who do not realize that they are dealing with a
quantity (delta) rather than a quantity_point (temperature point). We can,
of course, say that the users should know the affine space abstractions and
label this as a teachability issue. We have done this many times already
(even with views and ranges). However, probably much better would be to
make such a code to not compile.

Some of you suggested introducing two sets of units for Celsius and
Fahrenheit. This has a few issues that I pointed out in the previous emails.

My preferred approach would be to disable the support for the multiply
syntax for temperatures althougether. It can easily be done and should
serve the purpose. Also, we can consider completely removing the multiply
syntax from the library for all the quantities. One of our users already
asked for this in https://github.com/mpusz/mp-units/discussions/578.

With the proposed change, we would always have to write:

auto t1 = quantity{10, deg_C};
auto t2 = quantity_point{quantity{10, deg_C}}; // current design
auto t3 = quantity_point{10, deg_C}; // possible extension
with a new constructor overload

With this syntax, I think it gets really clear what we are dealing with in
each case.

How do we feel about such an interface?

śr., 19 cze 2024 o 09:03 Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> napisał(a):

> > The only place I know of where °C or °F are used anywhere but
> temperature points and in deltas is in talking about specific heat
> capacity, which is usually written in J/(kg °C) even though that's the same
> as J kg⁻¹ K⁻¹. There may be some other weird units (like the aforementioned
> ns/√km or kWh/1000h), but nothing that would be as widespread.
>
> I think you are very close to the same realization that I have.
> Lets push this a little bit further.
> Lets say you wanted to define an absolute quantity with units J/(kg °C)
> what does that even mean?
> How do I convert a quantity_point in J/(kg °C) to a quantity_point J/(kg
> °K)? (which you can do with every other unit)
> Do I
> X J/(kg °C) = X J/(kg °K) + 273.15 J/(kg °K)?
>
> The answer is... no one would ever do this!
> Every single time that you see °C combined with any other unit (like in
> J/(kg °C)) it always means the same thing as Kelvin.
>
> The only situation where you have °C and it is at an offset of 237.15 from
> absolute zero is when you are talking about an absolute temperature, a
> nowhere else EVER!
>
> A temperature of 15°C does not mean the same amount of stuff as a
> difference in temperature of 15°C.
> These 2 forms of °C are completely different units that apparently share
> the same name. It's a classification error! They are not the same thing!
> Because the difference between two temperatures expressed in °C is not a
> temperature in °C, it's a temperature in Kelvin! It always has been!
> But scientist are humans and also get confused!
>
> Stop them from ever being able to represent °C anywhere other than an
> absolute temperature, and they will never be wrong!
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2024-06-19 07:37:42