Association of units with physical types

[mhvk]

Over at astropy, we've been thinking a bit of how to associate physical types with units, in a way that is backward compatible. For defining units explicitly, this may be fairly obvious, just have an extra "physical_type" keyword argument, and likely that is all we would want to fix for interoperation.

But I thought it might be good to mention that we're also thinking about possible short-cuts in unit calculations. As an option, we're wondering about (see astropy/astropy#18521 (comment)) using __getitem__ as a way for the user to tell what the intended physical type is. E.g.,

s  = 1.23 * (u.J/u.K)["entropy"]
cv = 4.56 * (u.J/u.K)["heat capacity"]

Of course, another question is how this is used in actual calculations...

EDIT: Would be really happy to hear how other unit packages solve this!

[acottuli]

For reference, in ISO 8000-5:2019 [1] and the latest edition of the SI Brochure [2], "entropy" and "heat capacity" are listed as different derived quantities with the same SI coherent derived unit (joule per kelvin), and on page 140 of the SI Brochure they state that

It is important to emphasize that each physical quantity has only one coherent SI unit, even though this unit can be expressed in different forms by using some of the special names and symbols.

The converse, however, is not true, because in general several different quantities may share the same SI unit. For example, for the quantity heat capacity as well as for the quantity entropy the SI unit is joule per kelvin. Similarly, for the base quantity electric current as well as the derived quantity magnetomotive force the SI unit is the ampere. It is therefore important not to use the unit alone to specify the quantity. This applies not only to technical texts, but also, for example, to measuring instruments (i.e. the instrument read-out needs to indicate both the unit and the quantity measured).

In practice, with certain quantities, preference is given to the use of certain special unit names to facilitate the distinction between different quantities having the same dimension. When using this freedom, one may recall the process by which this quantity is defined. For example, the quantity torque is the cross product of a position vector and a force vector. The SI unit is newton metre. Even though torque has the same dimension as energy (SI unit joule), the joule is never used for expressing torque.

The SI unit of frequency is hertz, the SI unit of angular velocity and angular frequency is radian per second. The SI unit of activity is becquerel, implying counts per second. The use of the different names emphasizes the different nature of the quantities concerned. It is especially important to carefully distinguish frequencies from angular frequencies, because by definition their numerical values differ by a factor of 2π. Ignoring this fact may cause an error of 2π. Note that in some countries, frequency values are conventionally expressed using “cycle/s” (“cps”) or “revolution/s” (“rev/s”) instead of the SI unit Hz, although “cycle”, “cps”, “revolution” and “rev” are not units in the SI. Note also that it is common, although not recommended, to use the term frequency for quantities expressed in rad/s. Because of this, it is recommended that quantities called “frequency”, “angular frequency”, and “angular velocity” always be given explicit units of Hz or rad/s and not s^-1.

Special care must be taken when expressing temperatures or temperature differences, respectively. A temperature difference of 1 K equals that of 1 °C, but for an absolute temperature the difference of 273.15 K must be taken into account. The unit degree Celsius is only coherent when expressing temperature differences.

ISO 80000-5:2019 (p. 15)

ISO 80000-5:2019 (p. 7)

ISO 80000-5:2019 (p. 8)

The International System of Units 9th Edition (p. 139)

Also I'm not sure if it is worth modelling the difference in Python, but the 2nd committee draft of VIM4 [3] distinguishes between the concept of a "general quantity" and an "individual quantity" and there is a multi-page discussion about the different uses of the term "quantity" starting on page 55.

VIM4 2CD (p. 8)

[1] https://www.iso.org/standard/64976.html
[2] https://www.bipm.org/en/publications/si-brochure
[3] https://www.bipm.org/documents/20126/115700832/VIM4_2CD_clean/c6d0dfb2-ddbf-059e-1f74-9b025c9c59d8

[mhvk]

Thanks for those links! We've mostly discussed "individual quantities" as instances of the general Quantity class, though I guess in astropy we have examples of general quantities in our Angle and Distance classes.

Of course, for the discussion here I had been thinking mostly about how to indicate what general quantity a unit corresponds to. I hadn't realized that what we called "physical type" is also referred to as "general quantity". I wonder if we should try to standardize on some name for that. quantity_type?

[itsmiir]

The language is a little confusing--even in the SI brochure itself (the english version, at least) the word "quantity" is used to both refer to the "physical type" as defined here and a Quantity. I personally prefer the "physical type" wording--it's a lot less ambiguous than "quantity type" in my opinion.

[acottuli]

Thanks for those links! We've mostly discussed "individual quantities" as instances of the general Quantity class, though I guess in astropy we have examples of general quantities in our Angle and Distance classes.

Of course, for the discussion here I had been thinking mostly about how to indicate what general quantity a unit corresponds to. I hadn't realized that what we called "physical type" is also referred to as "general quantity". I wonder if we should try to standardize on some name for that. quantity_type?

Well "entropy" and "heat capacity" are ISQ quantity names, so I would just use quantity_name instead of physical_type or quantity_type.

The language is a little confusing--even in the SI brochure itself (the english version, at least) the word "quantity" is used to both refer to the "physical type" as defined here and a Quantity. I personally prefer the "physical type" wording--it's a lot less ambiguous than "quantity type" in my opinion.

IMO the main issue is that astropy (and Pint) define a Quantity as just a "number and a unit", contrary to the SI Brochure's guidance that "it is important not to use the unit alone to specify the quantity".

The C++ library mp-units avoids this issue by using ISQ named quantities [1] and quantity kinds (for grouping mutually comparable quantities).

I haven't given it too much thought, but if I was defining my own Quantity class in Python, I would probably use fields for value, unit, name (default=None), and kind (default=None).

Re the ISQ (International System of Quantities), @mpusz (mp-units creator) recently wrote a great series of blog posts [2] on the benefits and challenges of modelling the ISQ in code. Parts of it are only relevant to statically typed languages (like C++), but a lot of it is relevant to anyone trying to model the ISQ.

[1] https://mpusz.github.io/mp-units/HEAD/users_guide/framework_basics/systems_of_quantities/
[2] https://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/

[mpusz]

As @acottuli mentioned, I believe that units are not enough to properly model many systems and problems. Entropy vs heat capacity is only one of the possible issues here.

The problem you have does not exist in my library. In mp-units, you can solve it this way:

quantity s = 1.23 * isq::entropy[µJ/µK];
quantity cv = 4.56 * isq::heat_capacity[µJ/µK];
// quantity q = s + cv; // COMPILE-TIME ERROR

Check here: https://godbolt.org/z/jsW9r91nM

[lucascolley]

There was some previous discussion on Quantity Kinds, linked to from https://github.com/orgs/quantity-dev/discussions/4. I think the general sentiment was that we would want a ~mature Python implementation before we think about standardising it.

[mhvk]

@mpusz - that's neat! How does it work when you do calcations? If one had t = 7.89 * isq::temperature[K], would cv*t know that it is an energy? This is where having the unit first seems to have some advantage, so the unit can be calculated just from the other units, while one can add that it is an energy if needed, like (cv*t)['energy'].

[mhvk]

@lucascolley - makes sense; probably most important first of all just to agree on a common API for dealing with dimensions and physical types. Some experimentation will be useful!

[mpusz]

@mhvk - The library will store a derived quantity isq::heat_capacity * isq::thermodynamic_temperature which is convertible to isq::energy.

This is where having the unit first seems to have some advantage, so the unit can be calculated just from the other units

Well, this is not the case. In the case of units, you should not calculate the end unit (e.g., J from its ingredients). Just form the derived unit and allow the user to convert it to a required unit if needed. Otherwise, what will you do with 1/s, Hz, Bq, and Bd? There are other similar cases as well.

[mhvk]

Indeed, we calculate derived units too (though we cancel equal units; in this example, though, it would be J K/µK). Your "is convertible to" scheme sounds like the right one, which we would be the natural path for us too.

[mpusz]

Yeah, I cancel only the identical things as well.

[itsmiir]

Limiting the number of physical types/kinds and implementing conversion factors does mitigate the problem, but does it fully solve it? ex:

  quantity dist = 1.23 * isq::length[m];
  quantity radius = 4.56 * isq::length[m];
  quantity radial_force = 1.23 * isq::force[N];
  quantity tangential_force = 4.56 * isq::force[N];

  quantity torque = tangential_force * radius;
  quantity energy_expended = dist * radial_force;
  quantity q = torque + energy_expended;  // not caught by the compiler
  std::println("q = {}", q);

ref

I think that no matter what, there will always need to be some user input when constructing quantities. Unless you want to go full mathematical formalism...

Mathematically, I think that this specific situation is disambiguated because:

• dist is specifically a displacement, and radius is specifically a lever arm vector.
• torque is a (pseudo-) vector cross product, and energy_expended is implicitly converted from work, a scalar.

A more formal representation of the mathematics might be:

disp = [0, -1.23, 0] * m['displacement'] 
L = straight_line_to_origin(disp) # some representation of a path
ds = infinitesimal(L) # handwavy representation of ds
radius = [10, 0, 0] * m['lever_arm']
applied_force = [0, -10, 0] * N['force']
torque = cross(radius, applied_force) # lever arm x force is unambiguously (?) torque
work = path_integral(dot(applied_force), ds), path=L) # this variable unambiguously represents work

The idea of a physics package that enforces mathematical formalism to this extent is interesting to me, but decidedly outside of the scope of what we're talking about here.

[mpusz]

@itsmiir, your example is not right/fair 😉 The library can't understand variable names, and you provided the same types to 2 pairs of quantities that you use as a base of computation. If you use proper types, q will not compile. There are many ways to do it on many levels in computation. For example: https://godbolt.org/z/64G7v9s11.

However, you can check my Bringing Quantity-Safety To The Next Level article for a detailed description of the changes needed to improve that. Sadly, I didn't have enough time to finish this implementation, but hopefully it will be available soon.

[itsmiir]

@mpusz My apologies! I'm not familiar with ISO 80000-3; I didn't realize you had implemented it to that depth! Bravo!