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
>