mp-units: feat: raise level of abstraction from dimension to structure describing a quantity
#401 is too big of a step.
The quantity class template takes a template argument for the quantity dimension. The quantity_kind class template slightly extends them to describe the “is a kind of” property. The same happens for quantity_point and quantity_point_kind.
These are insufficient. And I don’t think extending quantity, like quantity_kind, did is the way to go. There are more properties than “is a kind of”.
A suitable structure, which describes these properties, should be used in place of the dimension of quantity. For starters:
- The structure should represent the name of the quantity and carry its dimension. With this, we can describe different quantities with equal dimensions. These should not be interconvertible.
- Then the structure can be expanded to describe the “is a kind of” property.
quantity_kindandquantity_point_kindcan go, which are replaced by a converting constructor inquanityandquantity_point(or whatever else according to how we define what a “kind” is). - The structure can be expanded with more properties:
- “Is a factor of”, e.g. radius is a factor of half of a diameter.
- “Is offset by”, e.g. a Celsius temperature point is offset by 273.15 K from thermodynamic temperature.
The last two are enough to also resolve #232, e.g. Fahrenheit is a factor of ⁵⁄₉ kelvin, and its points are also offset by 459.67 K.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 119 (82 by maintainers)
@burnpanck, could you please send me your private email?
For some context, see https://github.com/mpusz/units/issues/413#issuecomment-1376266683 and the last part of https://github.com/mpusz/units/issues/413#issuecomment-1376232546.
A radius is half of a diameter. @burnpanck correctly points out that the factor between these quantities only applies when converting one of these quantities to the other. So it is dependent on the object being measured. That is different from the conversion factor between temperatures differences, which apply between units.
With that in mind, it seems that comparisons should only look at the (number, unit) pair of the quantity arguments, as is customary. So $2\ m = 2\ m$ irrespective of the quantity kind either side of the equation represents.
Similarly, construction would only look at the (number, unit) pair of its input argument. Just like we commonly formulate that the radius 𝘢 equals $2\ m$, or the distance 𝘣 equals the width of bridge C.
That’s why I said
Thought I misspelled “as” instead of “is”.
Please excuse my continued long essays, I can’t help it 😃. Day-to-day business will prevent that soon enough though…
Oh and if you make radioactivity and frequency a separate and distinct narrowing kind of $T^{-1}$, then you also solve that case. So back to my question above: Why can we make height and radius “kinds”, but not frequency and radioactivity? Is there anything specific that ISO 80000 says about kinds?
Indeed, corrected to
radius(1m) + length(1m) = radius(2m). However you suggest that instead eitherradius(1m) + length(1m) = length(2m)or error-out. Returning a length seems to be at odds withfrequency + 1/time -> frequency(we just established the other is not wanted), and erroring-out is at odds with the convenience of the library.But I guess that will necessarily imply that you can construct a drag_coefficient from a plain force, which may be acceptable.
And, because we have now implicit down-casting, we should not support implicit conversion between radius and diameter. Consider the follwing:
This breaks associativityof
+:I started to work on that on the V2 branch already.