> This makes no sense. The formula to convert from Celsius to Fahrenheit is simply T_F = T_C * 9 / 5 + 32. This produces the correct answer in every case, and there is nary a Kelvin nor a Rankine to be seen. And it must be thus, because Celsius and Fahrenheit predate the Rankine and Kelvin scales by roughly a century!
> Back to the software perspective: it seems as though you propose performing additional runtime computational steps compared to the simple formula I provided just above. Why should we do that?


The difference in cost is just 1 addition in the most extreme case and it could be optimized. But now it is really hard to do the wrong thing.
You try to do something that is potentially ambiguous or dangerous, and the compiler says “No! fix it!” and it teaches you something, now you really have to pay close attention to what is happening and really know what you are doing.

That’s the point, it’s hard to do the wrong thing, if something happens it’s obvious.




From: Charles R Hogg <charles.r.hogg_at_[hidden]>
Sent: Tuesday, June 18, 2024 23:50
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 5:26 PM Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> wrote:
> 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.

"In a sense", but not in any sense that matters. It's true that the user "can't express" a temperature difference in Celsius. But the proposed interfaces don't make that clear --- and if a user tries to express it in the most natural way, the library will be happy to let them believe that they have done so.

> 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<http://temperature_celcius.to><units::farenheit>(); //would not compile

Hold on --- you lost me right here. Why exactly would this not compile? Why can we not convert temperatures in Celsius to temperatures in Fahrenheit? (As an American-born kid growing up in Canada, I seem to recall doing this all the time!)

//units::farenheit temperature_farenheit = temperature_celcius.to<http://temperature_celcius.to><units::kelvin>(); //would not compile
units::farenheit temperature_farenheit = units::farenheit{temperature_celcius.to<http://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<http://temp_difference.to>< units::farenheit >(); //would not compile
units::farenheit temperature_farenheit = units::farenheit{temp_difference.to<http://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.

This makes no sense. The formula to convert from Celsius to Fahrenheit is simply T_F = T_C * 9 / 5 + 32. This produces the correct answer in every case, and there is nary a Kelvin nor a Rankine to be seen. And it must be thus, because Celsius and Fahrenheit predate the Rankine and Kelvin scales by roughly a century!

Back to the software perspective: it seems as though you propose performing additional runtime computational steps compared to the simple formula I provided just above. Why should we do that?

+++++++
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.
+++++++

OK, thanks for clarifying. I definitely misunderstood your position until now --- I had indeed thought that you had an alternative design to offer for a standard units library. Instead, you're saying "no known units library design meets the bar for standardization; therefore, we should not standardize one".

That's fair: it's a very reasonable position. I agree that you've pointed out a design problem (i.e., the concrete code snippet in the original post). However, I disagree with the severity assessment: I don't think it's "intrinsic"; I think it's more peripheral. I think we can mitigate it by being judicious about what interfaces we provide for easily-confused dimensions such as temperatures. Thanks to the clarity of your concrete example, we will mitigate it!

But as for quantity point being some kind of deal breaker that makes the proposal unfit for standardization --- I'm sorry, but I simply don't see it.

Cheers,
Chip





From: Charles R Hogg <charles.r.hogg_at_[hidden]<mailto:charles.r.hogg_at_[hidden]>>
Sent: Tuesday, June 18, 2024 22:28
To: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>
Cc: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>; Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>; Chip Hogg <chogg_at_[hidden]<mailto:chogg_at_[hidden]>>; Anthony Williams <anthony_at_[hidden]<mailto:anthony_at_[hidden]>>; Johel Ernesto Guerrero Peña <johelegp_at_[hidden]<mailto: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