> But that's not the end of the story --- let's go further and imagine that this design gets accepted. Imagine a climate scientist has a temperature increase of 1.5 degrees Celsius, and wants to express it in Fahrenheit. What will happen? Will the library prevent this?

In a sense yes! As you wouldn’t be able to express a temperature difference in Celsius to begin with.

> It seems to me that the likeliest outcome is that they'll create a temperature of 1.5 degrees Celsius, and request conversion to a temperature in Fahrenheit, at which point the library happily provides a result of 34.7 degrees F, rather than the 2.7 degrees F I imagine they would have wanted.

But how would that look like?
If they just do:

units::celsius temperature_celcius{1.5};
//units::farenheit temperature_farenheit = temperature_celcius.to<units::farenheit>(); //would not compile
//units::farenheit temperature_farenheit = temperature_celcius.to<units::kelvin>(); //would not compile
units::farenheit temperature_farenheit = units::farenheit{temperature_celcius.to<units::kelvin>().to<units::rankine>()}; // ☹ ok I see what’s happening here

Then the mistake becomes apparent, you are converting trough the formula F = (°C + 273.15)*1.8 - 458.67, which happens always.
But more likely than not the code would look something more like this:

units::celsius temp_measure_1 {27.0};
units::celsius temp_measure_2 {28.5};
units::kelvin temp_difference = temp_measure_2 - temp_measure_1;

// units::farenheit temperature_farenheit = temp_difference.to< units::farenheit >(); //would not compile
units::farenheit temperature_farenheit = units::farenheit{temp_difference.to<units::rankine>()}; // ☹ ok I see what’s happening here

Which would also be transparent, since you are converting between the absolute units kelvin to rankine first and then from rankine to farenheit, and the complete process always follows the formula F = 1.8*K - 458.67.
There would never be any other way in which these units would convert between each other.

+++++++
Which is all well and good, we can discuss these different approaches all day.

But don’t misunderstand my position.
It is not that trying to convince you that should change the design of mp_units to be more adoptable by the standard.
I personally think that no unit library should be adopted, there’s no units library that I know of that tick all the boxes for me, right now it would be best used as a third-party library.

What I wanted to point out with this thread is:
A. The project has an intrinsic design problem.
B. Its possible to have an alternative design that doesn’t have these problems.
(maybe they might have other trade-offs, and those would need to be worked out with the same attention and rigor)
C. You should question that if given these intrinsic design problems, should we standardize this to begin with?

I’m not saying standardize something else. I’m just asking should we standardize this?

You may try to fix the design, and you should, I always support that (a better design is always better).
I’m just telling you what in my personal opinion I find wrong with it. Maybe in the future it will be better, but right now is not doing it for me.
+++++++




From: Charles R Hogg <charles.r.hogg_at_[hidden]>
Sent: Tuesday, June 18, 2024 22:28
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_[hidden]; Mateusz Pusz <mateusz.pusz_at_[hidden]>; Chip Hogg <chogg_at_[hidden]>; Anthony Williams <anthony_at_[hidden]>; Johel Ernesto Guerrero Peña <johelegp_at_[hidden]>
Subject: Re: [std-proposals] On the standardization of mp-units P3045R1



On Tue, Jun 18, 2024 at 3:58 PM Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> wrote:
> I'll reiterate my call for you to explain how you think a hypothetical standard units library ought to tell its users how to convert temperature differences from Celsius to Fahrenheit. Seriously: what line of code do you want to tell them to write?

You don’t have temperature in Celsius or Fahrenheit.

Thanks for answering! So it seems like your answer is "the standard units library should not support converting temperature differences from Celsius to Fahrenheit, because these temperature differences should not be representable in the first place". It's certainly not the approach I'd prefer, but I guess it's one point of view.

But that's not the end of the story --- let's go further and imagine that this design gets accepted. Imagine a climate scientist has a temperature increase of 1.5 degrees Celsius, and wants to express it in Fahrenheit. What will happen? Will the library prevent this?

It seems to me that the likeliest outcome is that they'll create a temperature of 1.5 degrees Celsius, and request conversion to a temperature in Fahrenheit, at which point the library happily provides a result of 34.7 degrees F, rather than the 2.7 degrees F I imagine they would have wanted.

Your original post provided a great service --- a concrete example where the current units library proposal would return a grossly incorrect result for code that looks correct. We can fix this if we avoid making it easy to create a quantity in situations where a quantity point is needed. By contrast, it seems to me that your proposal suffers from the exact same defect --- good-looking code that produces grossly incorrect results --- except that in this case, I'm at a loss for how we could fix it.

Cheers,
Chip