Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Should compound offset units be disallowed completely? #1350

Open
burnpanck opened this issue Jul 14, 2021 · 1 comment
Open

Comments

@burnpanck
Copy link

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.

@igurin-invn
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants