> Hence why I believe it is not fit for standardization, it is not just
“this is just a minor fixable problem”, it’s unfixable (at least not in
this way).

I do not agree with this statement and I think that you are over
exaggerating here.

According to the feedback we get from our users, mp-units provides the best
solutions for known problems in this domain. There is no better solution
that we know about.

I proved that your case can be easily correctly implemented in the library
if someone knows what (s)he is doing. The solution is not ideal, though,
and you proved that it may be misused by beginners in the domain in some
specific corner cases. This is definitely an issue that we should try to
address if possible. However, it does not mean that the library as a whole
is not fit for standardization.

We are open to ideas on how we can improve this and other cases.
Unfortunately, so far in this discussion, we have not found a good solution
that would be feasible to implement and would solve this issue without
breaking other things or complicating the library design to the extent that
LEWG will not agree on standardizing it.

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

> I agree that we disagree on this.
>
> I believe that ISO 80000 is demonstrably wrong on this point for reasons
> that I have explained.
>
> But regardless of what the ISO 80000 states, those problems that it causes
> are not going away, and that is what we are seeing here.
>
> And that’s why I think you will be unable to fix it.
>
> Hence why I believe it is not fit for standardization, it is not just
> “this is just a minor fixable problem”, it’s unfixable (at least not in
> this way).
>
>
>
>
>
> *From:* Mateusz Pusz <mateusz.pusz_at_[hidden]>
> *Sent:* Wednesday, June 19, 2024 11:22
> *To:* Tiago Freire <tmiguelf_at_[hidden]>
> *Cc:* std-proposals_at_[hidden]
> *Subject:* Re: [std-proposals] On the standardization of mp-units P3045R1
>
>
>
> 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
>
>