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
{{ message }}
Repository navigation
units: 's / m' and 's / m' are not convertible #8260
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 <[email protected]>
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.
I think I've got something. At the end of the problematic Maxwellian_1D function, we have a return distFunc.to(u.s / u.m). In what follows, unit is the unit of distFunc and other is u.s / u.m:
So I think this has something to do with that the fact that _powers are floats in one case and ints 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.
Activity
pllim commentedon Dec 11, 2018
Thanks for the details. That commit was part of #7649 . cc @mhvk
StanczakDominik commentedon Dec 11, 2018
Here's a more detailed traceback done from 3a478ca:
StanczakDominik commentedon Dec 11, 2018
I think I've got something. At the end of the problematic
Maxwellian_1Dfunction, we have areturn distFunc.to(u.s / u.m). In what follows,unitis the unit ofdistFuncandotherisu.s / u.m:So I think this has something to do with that the fact that
_powersare floats in one case andints in another. It may also have to do with the fact that_basesdon'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_basesfirst.mhvk commentedon Dec 11, 2018
Damn, and here I just moved the
unitsmodule indicator tostable! I'll try to trace down further (the hints certainly are helpful!)mhvk commentedon Dec 11, 2018
OK, here is an astropy-only version (proving it is purely an astropy bug):
mhvk commentedon Dec 11, 2018
The real problem is that the order of the powers is flipped, which means the bases are not sorted.
Fix bug with raising to a negative power.
mhvk commentedon Dec 11, 2018
Fix in #8263. This bug does show the risks of trying to special-case code for speed...