On Tue, Jun 18, 2024 at 2:43 PM Tiago Freire <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