units: 's / m' and 's / m' are not convertible
See original GitHub issueTo paraphrase from https://github.com/PlasmaPy/PlasmaPy/issues/587, exceptions like astropy.units.core.UnitConversionError: 's / m' and 's / m' are not convertible
(and a few other cases with first, second and third powers of second over meter, curiously) started popping up in our travis tests as seen at https://travis-ci.org/PlasmaPy/PlasmaPy/jobs/466396211 .
For a brief overview, running python setup.py test -d
and getting into plasmapy.physics.distribution.Maxwellian_1D
:
(Pdb) distFunc
<Quantity 5.91632969e-07 s / m>
(Pdb) p u.s / u.m
Unit("s / m")
(Pdb) p distFunc
<Quantity 5.91632969e-07 s / m>
(Pdb) p distFunc.unit
Unit("s / m")
(Pdb) p distFunc.to(u.s / u.m)
*** astropy.units.core.UnitConversionError: 's / m' and 's / m' are not convertible
I’ve managed to figure out that this is localized to astropy
3.1. As suggested by @astrofrog on slack, I ran git bisect
with pytest --doctest-modules $PLASMAPY/plasmapy/physics/distribution.py
and I was able to identify the first bad commit as
3a478ca29e86144d6c5a0305dde86169a647ff63 is the first bad commit
commit 3a478ca29e86144d6c5a0305dde86169a647ff63
Author: Marten van Kerkwijk <mhvk@astro.utoronto.ca>
Date: Thu Jul 12 21:01:28 2018 -0700
Further short-cuts for single-unit CompositeUnit initialization.
:040000 040000 1ba7cb9440215ab641197f91ef1623ad9bb39378 5c02db4ede9146ec12f84f57a0382f4900777544 M astropy
I’m currently trying to find out the exact cause of this bug in that commit, but I figured it’s best to submit this issue here before I accidentally close this tab or something.
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (5 by maintainers)
Top GitHub Comments
OK, here is an astropy-only version (proving it is purely an astropy bug):
I think I’ve got something. At the end of the problematic
Maxwellian_1D
function, we have areturn distFunc.to(u.s / u.m)
. In what follows,unit
is the unit ofdistFunc
andother
isu.s / u.m
:So I think this has something to do with that the fact that
_powers
are floats in one case andint
s in another. It may also have to do with the fact that_bases
don’t have the same ordering and thus you can’t simply (as I assume this does somewhere… haven’t been able to track it down) cast powers to a common numeric type and check if they agree. They have to be sorted with the same ordering that sorts_bases
first.