I know that you do not agree with that but many other people already
confirm that we we want to be able to express both a point and a difference
quantities in units like Celsius or Fahrenheit. Implicit mandatory
conversions of a difference type to Kelvin or Rankine is not an option here.

Also, again, I know that you do not agree with that, but ISO 80000
explicitly states:

> Differences of thermodynamic temperatures or changes may be expressed
either in kelvin, symbol K, or in degrees Celsius, symbol °C

and

> The unit degree Celsius is a special name for the kelvin for use in
stating values of Celsius temperature. The unit degree Celsius is by
definition equal in magnitude to the kelvin. A difference or interval of
temperature may be expressed in kelvin or in degrees Celsius.

We should be consistent with the official ISO standards for metrology.

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

> It will not solve the problem, because that is not the root cause.
>
>
>
> The root cause of the problem is that a quantity of 10°C does not
> represent the same amount of stuff as a quantity_point of 10°C
>
> And as long as you are able to create the two there will always be this
> confusion.
>
>
>
> The problem is not interesting because it is unsolved by mp_units, it is
> interesting because it is UNSOLVABLE with mp_units.
>
> It’s a problem intrinsic to the design!
>
> And it happens here:
>
> You don’t have a “quantity”
>
> You have a quantity<GAUGE_INFORMATION, underlying_type>
>
> And quantity<gauge_kelvin,…> is a unit of kelvin and
> quantity<gauge_celcius,…> is a unit of celsius
>
> But what you need is an offset_quantity<gauge_kelvin, offset_celsius, …>
> to mean a unit of celsius
>
>
>
> Unless you are able to annotate your “gauge_celcius” (or whatever the
> equivalently named type is) such that when used it in
> quantity<gauge_celcius,…> it won’t be able to do it (or make the math works
> differently),
>
> you will never be able to solve this problem with mp_units, and I don’t
> think you are ready to adopt this solution.
>
> And as long as you have a “gauge_kelvin” and “gauge_celcius” its borked.
>
>
>
> You may try to fix it, maybe you have a different solution in mind that I
> don’t see, and maybe you can fix it. But I do believe I have my finger
> exactly where the pain point is.
>
>
>
>
>
>
>
> *From:* Mateusz Pusz <mateusz.pusz_at_[hidden]>
> *Sent:* Wednesday, June 19, 2024 09:37
> *To:* std-proposals_at_[hidden]
> *Cc:* Tiago Freire <tmiguelf_at_[hidden]>
> *Subject:* Re: [std-proposals] On the standardization of mp-units P3045R1
>
>
>
> > 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
>
>