Date: Tue, 18 Jun 2024 15:55:53 -0400
On Tue, Jun 18, 2024 at 3:43 PM Tiago Freire <tmiguelf_at_[hidden]> wrote:
> > 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>
>
OK, that type exists. How does it support your assertion that there exists
an mp-units computation where the result contains a unit that is not found
in any of the inputs?
> *From:* Charles R Hogg <charles.r.hogg_at_[hidden]>
> *Sent:* Tuesday, June 18, 2024 21:31
> *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 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
>
> > 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>
>
OK, that type exists. How does it support your assertion that there exists
an mp-units computation where the result contains a unit that is not found
in any of the inputs?
> *From:* Charles R Hogg <charles.r.hogg_at_[hidden]>
> *Sent:* Tuesday, June 18, 2024 21:31
> *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 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
>
Received on 2024-06-18 19:56:05