On Tue, Jun 18, 2024 at 6:02 PM Tiago Freire <tmiguelf_at_[hidden]> wrote:

> > 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.
>
>
I agree that the cost makes no *practical* difference, especially because
well-written programs do not perform unit conversions in hot loops. I
apologize for distracting you from the substance of my post.

Returning now to that substance --- are you saying that converting a
*temperature* in Celsius to a *temperature* in Fahrenheit is a "potentially
ambiguous or dangerous" operation? Even in your preferred world, where
temperature *differences* in Celsius and Fahrenheit are not allowed to
exist? The latter policy, I can at least understand, even though I think
it is misguided. But the former, I am at a loss to explain.

Have I really understood you correctly, that you think we should prevent
directly converting temperatures between Celsius and Fahrenheit?



>
>
>
>
>
>
>
>
> *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]> 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<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<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.
>
>
>
> 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]>
> *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]> 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
>
>