> A quick grep of the mp-units repo shows that there is no type named "Temperatur", or "Temperature". And there is no namespace named "is". None of this code looks at all familiar to me.

Sorry, I tried to write it from memory and messed it up. I didn’t want pull out the code and ding up its entrails to figure this out as it is not very transparent.
The right type is this:

mp_units::quantity<mp_units::si::degree_Celsius, double>


From: Charles R Hogg <charles.r.hogg_at_[hidden]>
Sent: Tuesday, June 18, 2024 21:31
To: Tiago Freire <tmiguelf_at_[hidden]m>
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 2:43 PM Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> wrote:

> I admit that I have less working familiarity with mp-units than Au, simply because I use the latter in my day to day work. But could you please give a more explicit example where the result of an mp-units computation conjures up units that weren't mentioned in any of the inputs? I don't know any, but, again --- I'm less familiar.
The actual type is
mp_units::Temperatur<mp_units::is::degree_Celsius, double>
if I’m not mistaken

A quick grep of the mp-units repo shows that there is no type named "Temperatur", or "Temperature". And there is no namespace named "is". None of this code looks at all familiar to me.

here’s the template definition:

/**
* @brief A quantity
*
* Property of a phenomenon, body, or substance, where the property has a magnitude that can be
* expressed by means of a number and a reference.
*
* @tparam R a reference of the quantity providing all information about quantity properties
* @tparam Rep a type to be used to represent values of a quantity
*/
template<Reference auto R, RepresentationOf<get_quantity_spec(R).character> Rep = double>
class quantity;

and has only 1 member:
Rep numerical_value_is_an_implementation_detail_;

Yes, that is the definition of `quantity`. But how does this relate to my question?

You said that mp-units also "conjures up" units in the result of a computation that were not present in the inputs. (This is something that you propose to do, by returning the difference between two temperatures in degrees Celsius as a temperature in Kelvins. But I have not seen mp-units do anything like this since the 2.0 refactor, and I would be very surprised if it did.)

Were you perhaps mistaken that mp-units does this? Or did you have some other example to provide?

> This approach is what we might call the "arbitrary functional forms" approach. It's very ambitious for a units library, and there's a lot to like about it. I believe that in principle, there are use cases that this approach could handle that the quantity / quantity-point approach couldn't (although I don't know any off the top of my head).

If you had to handle things like logarithmic units, it would be this exact same solution, it’s a type whose math works differently, not some form of hyper-space concept.

Great callout! "Logarithmic units" (decibels, nepers, etc.) are a major unsolved problem for the library. I could well imagine that the "arbitrary functional forms" approach would do well here.

I think the concrete next step for solving logarithmic units is to gather a collection of subject matter experts, and come up with a set of "acceptance tests" --- cases that the library must be able to handle. Then we'd need to come up with a set of interfaces that can simultaneously satisfy all of the acceptance tests. I don't even know whether that's possible, for various reasons, but I'm hopeful that it is. :)

Incidentally, from what little I've learned of logarithmic units from their practitioners, it seems as though there's also a natural division into "quantity-like" (e.g., dB) and "quantity-point-like" (e.g., dBV, dBW) types.


> However, it seems to me that it has a defect: there are also cases that the quantity / quantity-point approach can handle, that this one can't. One example is the example earlier in the thread, which I'll decline to repeat in detail. Let's focus in on the part that I think would be harder for your approach. Suppose there's some climate scientist communicator who's using C++, and wants a reliable way to convert temperature change thresholds from Celsius to Fahrenheit. Suppose also that we take your preferred design approach in the standard units library. What are you going to tell this person to write?

They can use Celsius and Fahrenheit (or even Kelvin or Rankine) for “absolute temperatures”, for “temperature differences” (or math) you have to use Kelvin or Rankine, and this shouldn’t be strange to a climate scientist.

Just to be clear: the idea that you "have to" use Kelvin or Rankine for temperature differences is objectively false. It's perfectly coherent to have a temperature difference of 5 degrees Celsius. You can add it to a temperature of 20 degrees Celsius, and you'll get a temperature of 25 degrees Celsius. We never need to bring some external unit into this picture: not in real life, and not in well written software interfaces.

The idea that it "shouldn't be strange to a climate scientist" that temperature differences in Celsius don't exist is, of course, patently absurd. Climate science as a vocation has chosen to communicate the thresholds for temperature differences in units of degrees Celsius. Here is just one example: https://www.un.org/en/climatechange/science/climate-issues/degrees-matter

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?

Thanks,
Chip