-
Notifications
You must be signed in to change notification settings - Fork 477
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
Possible regression in UnitRegistry.get_compatible_units() #1115
Comments
1116: Harmonize most doctests with Pint's current behavior r=hgrecco a=clarkgwillison - [ ] Closes # (no single issue) - [x] Executed ``black -t py36 . && isort -rc . && flake8`` with no errors - [x] The change is fully covered by automated unit tests - [x] Documented in docs/ as appropriate - [x] Added an entry to the CHANGES file This PR partially addresses #947, #972, and #990 After merging, the number of failing doctests in the Sphinx documentation should go from 92 (as mentioned in #947) down to 3: ``` Doctest summary =============== 335 tests 3 failures in tests 0 failures in setup code 0 failures in cleanup code build finished with problems. make: *** [doctest] Error 1 ``` Which will put us well in reach of enabling doctests in Travis to prevent documentation regressions in the future. Most tests were fixed in this PR by deferring to the current behavior of Pint, however `Quantity.__repr__()` was modified to round floating point magnitudes to 9 digits to avoid several test failures that were being caused by floating point ambiguities. Issue #1115 was opened to track the 3 tests that I could not easily resolve. Once that issue is resolved, we can enable doctests in Travis without breaking CI. Co-authored-by: Clark Willison <[email protected]>
I think it is also a good moment to specify the behavior and write the docstring of "Return all non-prefixed units compatible with a given unit within the active system. Alternative, you can restrict the output to a specific group or system." |
Right now it behaves like this: >>> import pint
>>> ureg = pint.UnitRegistry()
>>> ureg.get_compatible_units('meter')
frozenset({<Unit('planck_length')>,
<Unit('fermi')>,
<Unit('classical_electron_radius')>,
<Unit('x_unit_Cu')>,
<Unit('x_unit_Mo')>,
<Unit('bohr')>,
<Unit('angstrom')>,
<Unit('angstrom_star')>,
<Unit('lattice_spacing_of_Si')>,
<Unit('micron')>,
<Unit('meter')>,
<Unit('nautical_mile')>,
<Unit('astronomical_unit')>,
<Unit('light_year')>,
<Unit('parsec')>})
>>> ureg.get_compatible_units('meter', group_or_system='mks')
... # (same as above) Should it behave like this instead? >>> ureg.get_compatible_units('meter')
... # (same as above)
>>> ureg.get_compatible_units('meter', group_or_system='mks')
frozenset({<Unit('meter')>}) |
If you don't provide a In order to change this content, we need to change the definitions file. I agree that most units there are not mks, but I wonder if some (like micron) should be kept for convenience. |
I get that sense also, somehow it needs to know what we mean by "compatible with MKS", and I'm not sure what should be included in that, or how to include that information in the definition file. To me that makes "narrow down the list..." a "new feature", and not a "bugfix". That makes me think the best course of action for now is removal from the docs. That will put the doctest errors at zero so doctests can be added to CI, it will also make the docs reflect the current state of the code. Once that's done, we can open an issue to help answer the questions:
Then the implementation work can be prioritized against other proposed features (i.e. left on the wishlist for new contributors). |
Isn't this linked to my question #1094 ? I noticed then that basically all units have SI in their systems, which would prompt a "full compatibility" as well, isn't it? Regarding the "narrow down the list" I can explain what I would use it for: a way to ensure all quantities inside my workflow are SI. I could check all quantities at the gate, and make sure they are "mks" compatible. In this sense, I assume prefixed SI units are not SI: I do not want km to be mixed with m, I do not want any conversion anymore inside the workflow, this has to happen at the gate. However, I expect N to be compatible mks, and not force me to kg.m/s^2. |
1124: Resolve remaining doctests, enable doctest in CI r=hgrecco a=clarkgwillison - [x] Closes #1115 - [x] Executed ``black -t py36 . && isort -rc . && flake8`` with no errors - [x] The change is fully covered by automated unit tests - [x] Documented in docs/ as appropriate - [x] Added an entry to the CHANGES file This PR pushes off fixing the `get_compatible_units(..., group_or_system='...')` feature mentioned in #1115, removing references to it from the docs for now. It also enables doctests in CI now that all remaining doctests are passing Co-authored-by: Clark Willison <[email protected]>
While doing work on the doctests, I noticed there's a significant difference between the output of
ureg.get_compatible_units()
and what's in the docs.The docs say "You can also use system to narrow down the list of compatible units" and gives the following example:
But when
.get_compatible_units('meter')
is run on f8ec2ca, many more units appear than just those in themks
system, includingnautical_mile
, which suggests either there's been a regression, or the docs are not up to date.Relevant test run output:
The text was updated successfully, but these errors were encountered: