Date: Tue, 18 Jun 2024 23:39:44 +0200
Hi,
> On 18 Jun 2024, at 22:27, Charles R Hogg via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Imagine a climate scientist has a temperature increase of 1.5 degrees Celsius, and wants to express it in Fahrenheit. What will happen?
The 1.5 degrees “increase” has to come from somewhere. It’s actually a difference: temp1 - temp0. That is likely written somewhere in the code (unless it’s deserialized). There were two values and we took the difference. And that’s exactly how I’d expect it to work.
Basically every user of a library will understand this (especially the climate scientists):
constexpr auto delta1C = 1 _deg_C - 0 _deg_C;
Maybe a bit verbose - not as much as explicit types -, but it captures what we mean: difference in temperature.
Also, I find it perfectly understandable to multiply a quantity_point: if you tell a 6th grade student, “y’day it was 30C, today 10% more, how much is it today?”, they’ll likely be able to answer. And yes, the amswer depends on unit, it’s different if you tell this in C or F (let alone K), but that’s still understandable I think (and it’s in-line with real-world expressions of the same concept). Way less confusing I think than 30 * deg_C not meaning 30C on the thermometer.
To be clear, this is not only about temperature: geospatial coordinates are similar when expressed in degrees. It can actually be more difficult as some location codings use characters (not sure what help the difference type and reference point would be of there). Also, financial calculations have similar issues (e.g. price-yield-risk). There, (mandatory) rounding might even mean that, in the value = quantity_point + quantity notation, quantity is not unique for a value (i.e., there are multiple ways to write the same constant with the delta notation) and quantity_point + quantity + quantity != quantity_point + 2 * quantity. (Same were true for date adjustment, had we had proper date algebras and date rules in chrono - so far, we have physics notation, which is still an improvement to struct tm.) So these delta-notations should be used carefully I think.
It’s not to demotivate - it’s how I’d consider improving it for units that are usually expressed on an absolute scale (with a reference point).
Bests,
-lorro
> On 18 Jun 2024, at 22:27, Charles R Hogg via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Imagine a climate scientist has a temperature increase of 1.5 degrees Celsius, and wants to express it in Fahrenheit. What will happen?
The 1.5 degrees “increase” has to come from somewhere. It’s actually a difference: temp1 - temp0. That is likely written somewhere in the code (unless it’s deserialized). There were two values and we took the difference. And that’s exactly how I’d expect it to work.
Basically every user of a library will understand this (especially the climate scientists):
constexpr auto delta1C = 1 _deg_C - 0 _deg_C;
Maybe a bit verbose - not as much as explicit types -, but it captures what we mean: difference in temperature.
Also, I find it perfectly understandable to multiply a quantity_point: if you tell a 6th grade student, “y’day it was 30C, today 10% more, how much is it today?”, they’ll likely be able to answer. And yes, the amswer depends on unit, it’s different if you tell this in C or F (let alone K), but that’s still understandable I think (and it’s in-line with real-world expressions of the same concept). Way less confusing I think than 30 * deg_C not meaning 30C on the thermometer.
To be clear, this is not only about temperature: geospatial coordinates are similar when expressed in degrees. It can actually be more difficult as some location codings use characters (not sure what help the difference type and reference point would be of there). Also, financial calculations have similar issues (e.g. price-yield-risk). There, (mandatory) rounding might even mean that, in the value = quantity_point + quantity notation, quantity is not unique for a value (i.e., there are multiple ways to write the same constant with the delta notation) and quantity_point + quantity + quantity != quantity_point + 2 * quantity. (Same were true for date adjustment, had we had proper date algebras and date rules in chrono - so far, we have physics notation, which is still an improvement to struct tm.) So these delta-notations should be used carefully I think.
It’s not to demotivate - it’s how I’d consider improving it for units that are usually expressed on an absolute scale (with a reference point).
Bests,
-lorro
Received on 2024-06-18 21:39:58