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

"h" should be the abbreviation of hours #719

Closed
eevleevs opened this issue Oct 15, 2018 · 14 comments · Fixed by #1454
Closed

"h" should be the abbreviation of hours #719

eevleevs opened this issue Oct 15, 2018 · 14 comments · Fixed by #1454
Assignees

Comments

@eevleevs
Copy link
Contributor

eevleevs commented Oct 15, 2018

"hr" is used as an abbreviation for hours, but this is not according to standard (see https://www.bipm.org/en/CGPM/db/9/7/), and much less common than "h" worldwide.

Here "h" is used for the Planck constant, which I think has much less use than the hours symbol. Both "h" and "hr" should be used for hours, to avoid misunderstanding. Planck should be called something else.

@jondoesntgit
Copy link
Contributor

Changing this now could break backwards compatibility. An alternate solution would be to define a different registry that is according to the CGPM standard, which would define Planck as something other than h, and define hours as h and hr.

@hgrecco
Copy link
Owner

hgrecco commented Oct 16, 2018

I think we should put constants into a namespace in the long run. But now I agree with @jondoesntgit here.

@jondoesntgit
Copy link
Contributor

How would namespaces mesh with Quanity? Say that I wrote a quantity:

Q_(1, 'h'), would the program assume that it's hour, instead of Planck constant? I can see this leading to unintuitive/unexpected behavior for new users.

@eevleevs
Copy link
Contributor Author

Not sure I get this. I think it's much more likely for a new user to expect h for hours rather than Planck.

@eevleevs
Copy link
Contributor Author

By the way I vote for having constants in another registry. They may work the same, but they are a different thing in concept.

@cpascual
Copy link
Contributor

Q_(1, 'h'), would the program assume that it's hour, instead of Planck constant?

If we ignore the backwards-compatibility issues, I think that the actual intuitive behaviour is to read Q_(1, 'h') as "1 hour".

Also, I think that separating constants from units is a good idea. IMHO constants should be Quantities, not units.

@jondoesntgit
Copy link
Contributor

Agreed that it seems uninutivite to define quantities based on units (1.72 Planck constants). I would, however, like to avoid a situation where Pint tacitly interprets u.h as Planck constant and Q_(1, ‘h’) as hour. The symbol should remain constant.

I think Scipy’s units package puts all its constants in a namespace.

@bilderbuchi
Copy link
Contributor

IMHO constants should be Quantities, not units.

Agreed, preferably this or at least separate namespaces for constants would help here. I was also just tripped up by the unintuitive parsing of "1h".

@akaihola
Copy link

akaihola commented Dec 1, 2020

Is there any simple work-around to create a custom unit registry in which h stands for hour?

@larstiq
Copy link

larstiq commented Mar 5, 2021

Grepping for planck in the codebase finds #82 where the alias h for hour was removed (in the opinion of the thread participants, that would be the wrong way around).

That happened in commit ae189a1 where pint/default_en.txt dropped the = h. That file is loaded in https://github.com/hgrecco/pint/blob/master/pint/registry.py#L268 if BaseRegistry(filename="") so it seems at least at that level one should be able to override with a custom registry. I did not check how the inheriting classes are handling this.

@jules-ch
Copy link
Collaborator

@hgrecco

IMO we should make a breaking change for this case, since it is really disturbing for new users & can potentially introduce bugs when using pint.

I like the idea of a dedicated namespace, but it's difficult to implement since we rely only on strings in the file definition.

Following BIPM standard & ISO/IEC 80000 series Quantities and units & IUPAC Green Book, roman font is used for units & italic symbols for quantities to avoid any ambiguity.
This could help us to differentiate between constants, that are quantities.

@jules-ch
Copy link
Collaborator

jules-ch commented Jun 16, 2021

At least for the hour vs planck constant case, we can use unicode for planck constant.

@jules-ch jules-ch self-assigned this Nov 24, 2021
@Flix6x
Copy link

Flix6x commented Dec 21, 2021

Is there any simple work-around to create a custom unit registry in which h stands for hour?

@akaihola Not sure if you'd qualify this as "simple", but here's a hacky workaround:

import importlib.resources as pkg_resources
import pint

# Edit constants template to stop using h to represent planck_constant
constants_template = pkg_resources.read_text(pint, 'constants_en.txt').replace("= h  ", "     ").replace(" h ", " planck_constant ")

# Edit units template to use h to represent hour instead of planck_constant
units_template = pkg_resources.read_text(pint, 'default_en.txt').replace("@import constants_en.txt", "").replace(" h ", " planck_constant ").replace("hour = 60 * minute = hr", "hour = 60 * minute = h = hr")

# Join templates as iterable object
full_template = constants_template.split("\n") + units_template.split("\n")

# Set up UnitRegistry with abbreviated scientific format
u = pint.UnitRegistry(full_template)
u.default_format = "~P"  # short pretty

Check:

>>> u.Quantity("h").dimensionality
<<< [time]
>>> u.Quantity("planck_constant").dimensionality
<<< [length] ** 2 * [mass] / [time]

@hgrecco
Copy link
Owner

hgrecco commented Dec 21, 2021

@jules-ch
Checkout my comment here:
#1078 (comment)

What do you think of this approach for constants?

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

Successfully merging a pull request may close this issue.

9 participants