You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This library offers the functionality of "offset units", which are used to describe points on a scale, instead of distances between such points, as is usually the case. The specific use-case are temperatures, such as degC and degF.
It also offers the ability to create quantities with units such as degC**2 or degC m. However, it turns our that these fail most operations. It's unclear what a product between a point and a distance on a different dimension would physically mean, as much as a multiplication between a point and a number should mean.
The fundamental issue with that is probably that, physically, there are no offset units. Instead, there are quantities representing distances (the usual ones), and quantities representing points on a scale.
That is, being of the "offset" type (or maybe better "point" type?) or not is actually a property of the quantity, not the unit.
A compound unit "lives" in a different dimension than it's constituent base units, and therefore necessarily any points on that scale must be unrelated to the base unit scales.
Because of that, some other physical quantities packages that I'm aware of (mainly C++) actually implement QuantityPoints as a different type of Quantity, rather than a different type of Unit.
The problem with that approach of course is that at least in the case of temperatures, we do imply a specific reference point by our choice of unit, iff the temperature is implicitly to be interpreted as a temperature point. All quantity packages struggle with providing a suitable method for the user to specify if a provided temperature value is to be interpreted as a point or a distance. Pint handles this by providing two separate units (e.g. degC and delta_degC) to distinguish the two, but now conflating that property of the quantity of being point vs. distance with a property of a unit.
In order to prevent potential surprises with such unclear compound offset units, I think it might make sense to disallow them completely.
The text was updated successfully, but these errors were encountered:
Agree. In my work, I know I tend to be pedantic, but I avoid using deg C unless I really mean deg C. All my temperature increments (even when I'm not using a units tool like pint) are annotated as K.
This library offers the functionality of "offset units", which are used to describe points on a scale, instead of distances between such points, as is usually the case. The specific use-case are temperatures, such as
degC
anddegF
.It also offers the ability to create quantities with units such as
degC**2
ordegC m
. However, it turns our that these fail most operations. It's unclear what a product between a point and a distance on a different dimension would physically mean, as much as a multiplication between a point and a number should mean.The fundamental issue with that is probably that, physically, there are no offset units. Instead, there are quantities representing distances (the usual ones), and quantities representing points on a scale.
That is, being of the "offset" type (or maybe better "point" type?) or not is actually a property of the quantity, not the unit.
A compound unit "lives" in a different dimension than it's constituent base units, and therefore necessarily any points on that scale must be unrelated to the base unit scales.
Because of that, some other physical quantities packages that I'm aware of (mainly C++) actually implement QuantityPoints as a different type of Quantity, rather than a different type of Unit.
The problem with that approach of course is that at least in the case of temperatures, we do imply a specific reference point by our choice of unit, iff the temperature is implicitly to be interpreted as a temperature point. All quantity packages struggle with providing a suitable method for the user to specify if a provided temperature value is to be interpreted as a point or a distance. Pint handles this by providing two separate units (e.g.
degC
anddelta_degC
) to distinguish the two, but now conflating that property of the quantity of being point vs. distance with a property of a unit.In order to prevent potential surprises with such unclear compound offset units, I think it might make sense to disallow them completely.
The text was updated successfully, but these errors were encountered: