Date: Wed, 19 Jun 2024 09:49:21 +0000
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_hotmail.com<mailto: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]m<mailto:mateusz.pusz_at_[hidden]>>
Sent: Wednesday, June 19, 2024 09:37
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]<mailto: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]<mailto: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]socpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
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_hotmail.com<mailto: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]m<mailto:mateusz.pusz_at_[hidden]>>
Sent: Wednesday, June 19, 2024 09:37
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]<mailto: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]<mailto: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]socpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-06-19 09:49:26